Probably the biggest surprise I've seen in my career as a team lead is how often people ostensibly work with the team, but actually want to see the team fail. It sounds ridiculous, I know, but it actually happens quite often.
Here are two quick examples where I see this happen often. Let's say you're a vendor deploying software at an organization, and one or more people that work at your client organization originally wanted to write their own solution for this software, and their bosses overrode their wishes, and now they're forced to help implement your software. You need to use those disenfranchised IT people as part of your team to do the implementation, but they'd like to see the project fail, because they told their manager they could do it better themselves. Other variations of this occur whenever someone doesn't get their way, and is forced to go implement things a different way -- now any delays that happen may demonstrate their sage wisdom in not wanting to do it this way.
I've also seen variations on this same theme where a company is working on a product that does what we're implementing, but it's not ready yet. Then a year down the road, when we're doing the final rollout, their product is almost ready, so now they'd like to see us fail. And suddenly the alliance falls apart. Over the last 30 years working in IT, I've seen something like 20-30 variations on this theme.
Lots of times you need to work with people who really want to see your project fail. This came as a huge surprise to me, but I think any senior person should be careful and on the lookout. It's often a significant project risk, and almost always overlooked.
I've definitely been that person who didn't want the project to succeed - and I was the key developer (and an external consultant). I was convinced that we were implementing the wrong thing. Even though I tried to suck it up and do the job, it was hard to do my best on something I was sure was going to fail.
I had to be talked out of quitting a couple of times. I think they might have been better letting me quit the first time, and getting a replacement who didn't have so much ego affecting their work.
I wouldn't call that "brave". "Putting ego aside" is hard, requires a lot of work and in most situations it's a safe thing to do. Hence no bravery here, maybe loyalty would be a better word.
He was being brave when he brought his problem to his superiors and said he'd like to quit. Actually, the only "braver" thing in this situation would be to quit anyway, without letting them "talk him out of quitting". But that could have been also stupid, we don't know the exact circumstances.
On a more general note: everyone should try to ~~contain~~ [edit: solve!] his/her ego-issues (and other psychological issues) as much as possible, of course. But placing someone with mentioned issues on the project which caused these issues in the first place is clearly a fail of management. If "soft skills" are so important (and they are), then the management should use them! Management should place employees in an optimal environment so that psychological issues are less likely to occur. Making people work for a long time on things they are averse to is a recipe for disaster. Both for the employee and the project.
In fairness, he did say he tried. Perhaps there was a lack of bravery, perhaps he could have gone to this bosses and explained the situation, but perhaps he did that and it wasn't enough.
It's also likely that he didn't realize what he was doing at the time. Maybe he felt upset or stressed about the situation but not necessarily that he was subconsciously hoping to failure.
One example of this, and it happens too often, is when people are training their replacements.
Jobs are sent elsewhere (outsourced, off-shored, or both) and the people currently doing those roles need to train up the people who will be taking them over.
I know one government department that decided to relocate a particular job function to another location as part of a broader "regionalisation" strategy. The people doing that job at the existing location were all going to be made redundant once the new team was ready to take on the work.
The old team had an economic incentive to make the handover take as long as they could. The new team didn't have a lot of incentive to make it go fast. Sure, they were keen to do some real work, but they were also reasonably happy to only have 50% of the case load, and leave 50% back with the original team. Since only the people at the top had any real desire to see the project succeed, you can probably guess how well it went.
To be fair, training your replacements when an entire division is being outsourced to off-shore is incredibly cruel.
My father in law works at an industrial manufacturer where several departments (including IT) are being outsourced to Southeast Asia. The company has been operating locally for nearly a century and a lot of the people who are being made redundant have worked there for decades and are now being kicked out at a point where they are too young for retirement but too old to find new jobs.
I know that a company isn't a welfare organisation, but if you employ upwards of a hundred people in a small town you can't deny having some social responsibility. It's easy to see why the workers told to train their cheaper replacements are having a hard time staying professional.
Why does a company have a "social responsibility" towards a bunch of wealthy Americans, but none towards the very poor southeast Asians who were denied for decades even the opportunity to apply for work at the US facility?
And the social responsibility arises from shaping the local economy in such a way that a large number of people become dependent on the company. If a company becomes the main employer in a small town, it automatically takes on some responsibility. This is less true today when most people know they're not going to work for the same employer until retirement but it is still true for traditional companies with that kind of legacy.
It's not about some theoretical ethical responsibility for the greater good of mankind but about taking responsibility for your actions and the effect they have on people you have built a relationship with. If Industrocorp, Inc builds a factory in Podunk and the labour demand raises the number of residents by an order of magnitude, then relocating operations and firing a large number of staff will ruin the local economy the company created.
I'm not sure how that concept is difficult to understand: your actions have consequences, ergo you are responsible for the consequences of your actions. Large corporations may be amoral, but the CEO of a privately owned company deciding to offshore half the employees isn't. Especially when the company periodical repeatedly claims that the employees are valued and their families are important. This makes the CEO an asshole. Period.
The consequence of not shipping jobs to southeast Asia is that folks there will be vastly poorer than unemployed Europeans. That isn't theoretical, its simply a fact.
Why does a non-contractual relationship change things? Are you applying the Copenhagen theory of ethics or something?
Every member of society[0] (including corporations) actions within the social contracts of that society. Society provides corporations certain affordances, in return corporations contribute to society (by paying taxes, reasonable wages and so on). Corporations don't have any god-given rights of their own, they merely have the privileges granted to them by society (via laws and regulations).
I realise HN is a weird place to argue this, but corporations don't exist in a vacuum. They can't exist in a vacuum. Without a state guaranteeing its rights and the means to enforce those rights, a corporation is just a group of individuals. This is not only true for corporations. You don't have any rights other than those afforded to you by society (whether on a local level like the US or a global level like the UN). If there's no-one who's going to enforce your rights, they become purely philosophical (cf. Guantanomo -- unless you believe the UN is going to take on the US government and bail you out of there).
The social contract is primarily between an individual and society at a local level. Thanks to globalization it now extends to other societies across the globe, but the responsibilities of a local corporation to residents of a country on the other side of the globe they don't already have any business relationships with is only secondary at best.
That said, you're kidding yourself if you are trying to argue that increasing profit (or cutting costs, which boils down to the same effect) by outsourcing to cheaper markets could even remotely be considered something ethically positive.
[0] I'm using the terms "society" and "state" or "government" interchangeably here based on the democratic principle that a state derives its legitimation from the people, i.e. the society it governs.
The social contract is primarily between an individual and society at a local level.
What makes the social contract local? Why not say the social contract is primarily between and individual and his race, his class, his clan or his religion?
At one time it was considered a violation of the "social contract" for a white man to hire cheaper negro workers (language chosen to evoke that era). Many folks still consider it a violation of the "social contract" to hire someone who isn't Marathi. Why do you choose geographic locality rather than race?
Outsourcing to cheaper markets reduces poverty and inequality. As a person who doesn't consider Debbie more valuable than Deepika (both are real people that I know personally), I consider helping Deepkia (born into dire poverty and with little chance to escape) far more ethical than helping Debbie.
You're asking questions that have been discussed at length by philosophers, and while there is no definitive "answer", there are some thought frameworks you can think in. Questions of ethics are hard because they're dependent on culture, and their axioms do not stem from nature (although a few philosophers claim they do) but from human psychology and social-psychology. Still, they're not completely arbitrary. You can say your values make you prefer ethical framework A over ethical framework B, but each framework -- while may not 100% logically sound and 100% consistent -- at least frames the discussion.
So, to get back to your question, there are certainly reasons -- within a given ethics framework -- to prefer local responsibility. The reasons start with the question, "why do I have a responsibility towards the Other[1]?" Some philosophers (like Levinas[2], I think), take a very total approach. Others may say that the responsibility stems from relationship and mutual influence (my wellbeing is affected by the Other, and the Other's is affected by mine). If you prefer the second approach, it is clear that you have greater responsibility towards those whose lives are more affected by yours and vice-versa, and as mutual effects can travel through the economy or legislation (you both vote for the same government), and those are local, it stands to reason that the measure of responsibility grows with locality. Other ethical frameworks may agree with this notion of locality in principle, but say that locality only takes precedence when the needs are the same (of the local and remote), but if the remote person/community has greater needs, then that takes precedence over locality.
All of these can make sense, and different people can subscribe to different ethical frameworks. But each of them has to be consistent, or at least have good reasons for breaking the consistency in some circumstances.
No, but I don't claim companies owe any responsibility to people in their hometown either. Certainly if companies do owe something beyond wages for work performed, I can't see why it wouldn't be owed to the poor rather than the rich.
Why don't the southeast Asians just create their own companies and jobs? Why do you assume that Europeans and Americans have to create jobs there in order for income to be equalized? You are missing a few things before you can say "its simply a fact." It's not a fact and there are many points in history where it has not been true.
Pitting the global working class against one another in this fashion will simply drive down wages across the board. Taken to the extreme, eventually the American, European, and SE Asian will be equally poor while c-level executives and investors continue increasing their wealth.
Your idea makes a certain kind of sense, but it's not going to lead to anything except even more inequality than we started with.
Hey, great point ! I wanted to buy property in Thailand but found I'm not legally allowed to because I'm not a Thai citizen.
That's got me thinking, what about the social responsibility of southeast Asians towards Americans who have been denied for decades the opportunity to own property and live in southeast Asian countries?
Every country has it's own laws about who can settle and work and under what conditions. America does it and so do 'Southeast Asian' countries and everywhere in-between.
Thailand decides who can own property (or work) there. It's neither racist (as you seem to imply - but perhaps you mean only when it's America?) nor is it evil.
Guess, I'll just need to suck it up and go without that great beach house in Thailand.
I'd certainly say that the Thai government are behaving in an bad manner towards prospective home buyers. It's not quite as bad - they aren't forcing Americans into dire poverty - but its certainly not an ethical move on their part.
I don't know the Thailand govt well, but India has similar laws and is explicitly racist about them.
Huh? How many southeast Asians were denied for decades employment at a company in small town USA?
Regarding social responsibility, this is simply my opinion, but companies that wish to employ the full legal and financial protection of the United States and operate within its infrastructure bear some social and moral responsibility to contribute back into the system. Offshoring the bulk of a company's workforce or moving profits overseas to evade taxes and other things of this nature should disqualify any company from receiving the protections and benefits provided by the US, full stop.
>often people ostensibly work with the team, but actually want to see the team fail
I've definitely seen this as a very common proclivity of small, poorly structured teams, over 30+ years of software development experience.
"Buy-in", or .. the phenomenon of staff actually buying into the project, and investing themselves in the effort required to realize a particular vision, actually requires them to agree with the project policies and strategy. If people in the team do not agree - like, actively, not just saying 'I agree' - not much work ever really gets done.
People who feel they have to covertly work to make a team fail need to realize where the failure really starts: in the decision to do so, without communicating about it.
Whereas, on the other hand, teams who really like each other - enjoy the project - use the technology well - and are open about the things they do not like about their daily/weekly work load - often accomplish amazing things.
It all starts with the decision to make something happen. If that decision is made for you by someone else, either buy the decision or don't. Loitering around to 'do the right thing and destroy the project/be there when it "inevitably fails"' is quite a disastrous contribution, in my opinion. I encourage everyone I work for - subordinate or superior, or otherwise - to keep things clean. Work, or leave.
One way to look at the first case is as a morale issue. They were excite d to plan and roll out their solution and have been "demoted" to gluing pieces together. Even if not actively wanting the project to fail, they won't be top contributors.
You're right. I've also often seen it where the disenfranchised people are the ones who wrote the original system we're replacing. And we need their help doing extracts for data conversion, and possibly interfacing to special systems only they know about. Same situation-- it can feel like a demotion.
It's important to take special care to get those people on board.
1. Make them feel like you like them. Show a real and genuine interest in and admiration for them and the work they have done, and look for opportunities to tell them how brilliant they and their work are. It's important to be genuine and not blow smoke up their ass too much; look for opportunities to be genuine about this.
2. Get them to say they are committed to the team, committed to the project, and will do everything they can to get it to succeed. Once someone says something, they tend to remain consistent with it. Getting them to publicly declare it somehow is good. Also getting them to declare publicly related things such as "I'm a team player" somehow can be very helpful and alter the course of their thinking.
3. Show how other people are pushing for the team, and build bonds between these people and their teammates. People will walk through fire for the love of their team.
All if those ideas are elaborated on in the book "Influence", thee are 3 of the 8 or so major themes of that book.
It's Influence by Bob Cialdini. I've also read How to Win Friends and Influence people, and it's very weak in comparison. The Cialdini book is rigorously researched and backed by science.
There are 2 perspectives to be aware of: theirs & yours.
You are replacing something they wrote. That in a way is saying what they wrote is obsolete.
Ask yourself why are you and other new members are working on this project; for your own advancement or for the good of the company. If the reason is the former, there's going to be a big ego-clash.
Look for win-win:
* The original team wrote the system and have learned valuable lessons from it over time. Ask them if they could write it now using current tools, how would they improve. Sell them the vision that the success of the project depends on their knowledge, and they can learn new tools, language, patterns, from the new members.
* The newer members can bring new ideas (backend, UI, etc). Sell them the vision that the success of the project depends on the new skill set that they bring.
Since you cannot change the original team composition, balance it by choosing the new team carefully, e.g., choose people who are goal-driven, and result-oriented; they care more about getting things done then throwing their weight around.
The former is also a leadership problem at the company. Let's have a vigorous and open debate while we're leading up to a decision. That's healthy.
Once a decision is made, it becomes everyone involved in the implementation's job to make it successful. If someone is openly running counter to that and isn't corrected or removed (at least from the project, and possibly from the company), you have a basic and straightforward leadership problem, IMO.
(In the second case of inter-company alliances, that's more normal and less amenable to a simple solution. It's also far less cancerous if left unchecked.)
> Once a decision is made, it becomes everyone involved in the implementation's job to make it successful.
The problem is the people who make the decisions are rarely the people who pay the price for bad decisions. I've worked with many vendors who promise integration will be straightforward and that their software is easy to extend to handle the last 10% of our business flow that it doesn't currently cover.
In truth its usually a huge pain and time sink and it's the developers (on both sides) who end up working crazy stressful hours to get the project finished.
How can you expect the developers to go the extra mile and fix your dumbass decisions when you didn't listen to them in the first place?
I was at a company where a vigorous debate was held on a technology decision. People failed to understand the difference between a democracy and anarchy. Or even between a team and anarchy.
Sometimes everyone has to pull on the same side of the rope.
I'm not specifying (and don't believe) that democracy is the best way to resolve a technical debate, but I am saying that once a path is decided, however decided, you pull in that direction or you need to be removed.
The people who aren't convinced can feel that the debate is still open, even while the majority is convinced that a decision was made two months ago.
I'm in the Netherlands, where hierarchy is a bit of a dirty word, and educated employees are all expected to be critical, independent, outspoken thinkers all working towards a common goal. That has many advantages, but the technical discussions about pretty small details can go on forever...
To me it indicates that you don't have a good facilitator in discussions. IMO one of the nicest things I've ever learned is the "silent thinking" bit. Basically: don't say anything, people write post-its, then people present that. This avoids usual influential people from speaking up early and everyone just focussing on one or two ideas. I've often been surprised what some people come up with.
If above is not enough to get an agreement, let the two people work it out on their own with a limit on how much time they can spend on it (and really limit this time). No need to have an entire team listen in or extend an existing meeting for ages (meetings should be brief).
Aside from that, sometimes you just need to do. So something like "it's not a perfect decision, but what you're saying is known and now it is time to do".
I'm from the Netherlands btw, though 50% of my colleagues are foreign.
People not knowing what decisions have been made, and which have yet to be made, is poor communication. The first thing you do after making a decision is communicate it unambiguously.
> Lots of times you need to work with people who really want to see your project fail.
Then you should seriously rethink whether the way you handle your project is good. Either you convince your team, or they convince you. If you have to fall back to the power your position gives you, either your angle is wrong or you fail to communicate. Either way, the problem is never the people, but you.
PS: I learned that the hard way and I am incredibly grateful to all those people in my teams who openly told me.
You say "convince". I don't think that has application to many technical discussions. Often these aren't settled on merit, because they're not actually technical at all. It surprises and disappoints me that many of the most heated arguments at work are really discussions about human factors.
Pretending that all discussions are going to be resolved amicably ignores ego, laziness, resistance to change, dislike of being publicly gainsaid, unwillingness to admit to mistakes, obsession with what's cool and so on.
These are never going to go away. The very best managers can take these conflicting concerns, balance them, and make a choice while explaining to all that yes, what they said is interesting and important but no, they don't always get their way.
The less good managers, i.e. most of them [us - I used to be a manager, but I wasn't very good at it] lack that ability and so arguments rumble on, grudges fester and somewhere along the line, someone who might be a sweetheart most of the time will take malicious glee in screwing things up.
There's always a reason behind a decision that can be explained to a group of people such that they understand and accept (if not agree) with it. A decision very well might have nothing to do with engineering. That's fine, and it's acceptable to say: "We're making this decision because of X."
It's better to expose everyone to the full business context so that they understand what the priorities are (within reason). From experience, engineers and scientists aren't always training themselves to consider business value. Sometimes it requires a step back to say, even though this is worse from an engineering perspective it's better from a business perspective. We're all here to serve the business, so let's do what's right for the business. Software doesn't exist to serve itself.
Maybe we know how to engineer and manufacture the best widget in the world, but the widget market is falling off, and we need to build a wamboozle instead.
People understand this stuff. The failure is often a failure to explain it.
There is an implicit assumption that in the workplace, we're all rational adults. Reasonable people who deep down are all the same and just want to do the right thing for the company. That is usually true, but a leader should keep in mind that often it is not true. I disagree with your apparent assertion that people never have irrational and destructive motives at work.
Sure, I've sabotaged outside vendors that came in myself.
One Fortune 500 company I worked for set up a fledgling out-sourcing group. I would see the tickets come up and I grabbed every one of them. I also watched for their caller ID on the help line and picked those calls up. My modus operandi would be to just not do any of the work they needed. Luckily for me, they usually didn't dot every i and cross every t with their requests. Usually we would hand hold most people, but I used this as an excuse not to do them. I remember the group manager screaming at me that he was paying a tech to sit there all week and the tech was not doing any work because I was blocking him from getting e-mail, logins and so forth. Then the next week they managed to figure out how to talk to my manager, but I had been doing a good job on everything else so far, and showed my manager how their requests were imprecise (of course, usually I helped people fill any gaps on the requests). I set up that account that day, but managed to quash or delay a lot of their other requests.
Within a few weeks I was transferred to a better position on another team, so their requests may have started going through faster, but I had probably managed to put their project behind schedule for a few weeks.
In her book "Nickled and Dimed", Barbara Ehrenreich talks about applying to some minimum wage job and on the application it said something like "Me and my employer have united interests" with her able to agree completely (a 5) to disagree completely (a 1). I saw a similar question when I applied to a minimum wage job years ago. I thought of her book, and the opening words of the preamble of the IWW constitution "The working class and the employing class have nothing in common". Of course I put a 5, that I thought my interests and the big retailers interests were completely aligned :) .
One of the first books on the subject of computer crime, "Computer Crime" by Donn Parker, tells employers that their worst problem is not outsiders, but their own employees. It goes back to the IWW constitution, or William Jennings Bryan's Cross of Gold speech. Or FDR's 1936 speech at the Democratic national convention about how "conditions of their labor - these had passed beyond the control of the people, and were imposed by this new industrial dictatorship". A speech after which FDR won over 60% of the vote and all but two states. Those who work and create wealth are a class different than the parasites and heirs who control and live off our labor. When the word comes down from on high that our work decisions are to be sabotaged more than usual, it's natural for us to sabotage the sabotage. It's in the nature of the relations of production at this stage of our society.
My interpretation: Assuming the work was outsourced to cheaper laborers (e.g. in India), OP may have felt that his job was at risk. By sabotaging the efforts of those offshore workers and making them appear incapable, he hoped to discourage management from outsourcing that work.
Is there aught we hold in common with the greedy parasite,
Who would lash us into serfdom and would crush us with his might?
Is there anything left to us but to organize and fight?
[0]
In my common role as a "fixer", someone called in or hired to rescue a failing project, one lesson I learned the hard way was to make sure the organization hadn't kept the person responsible for the failure on the same team, generally with a demotion. He would invariably continue to mess up the project; very possibly unconsciously, I figured one reason was that only continued project failure would validate his prior failure.
That, and just plain incompetence, e.g. back in the bad old days of 8088 IBM PCs, when people frequently programmed in C, it wasn't safe to hand such a person the responsibility of error reporting code, which could easily crash the whole application (real example).
> does wildly inappropriate acts such as coming in late and/or leaving very early
Man, am I glad I do not work on your team. If you judge coming in late or going early as inappropriate, as opposed to measuring actual results, then you have failed as a leader already. Sorry.
Indeed. I read that line and actually laughed out loud. On my team people regularly arrive in the office any time between 7am and 12pm. The notion that anyone in a modern software development job would care about the specific hours someone spends in a seat is ridiculous to me. You're either getting shit done or you're not, and you're either communicating in an appropriate and timely manner or not. If you're doing both of those things, who gives a fuck which specific block of hours your ass is in a specific seat?
Well, as stated very well above by timv, it works both ways. The "as long as you deliver you can work whenever you want" can be abused to expect more than full time work with a constant workload of above full time (bad estimates etc)
The agreement between me and my employer is that I work 40h per week, and deliver value during that time. Apart from that there is an understanding that I can work slightly more or less depending on workload and deadlines. What's important is that the long term average is never more than 40 (that would indicate and encourage bad estimates and bad deadlines). If I need to pick the kids up at 4 I pick them up at 4, deadline or not. If an employer felt it was a problem that I need to pick my kids up at 4 on deadline day they need to find another deadline or another developer.
Regarding work hours - I'm not expected to be in my seat during specific hours but should be available during office hours. Having teammates who cooperate not work overlapping hours would be very bad for productivity. If I need to do some extra hours I try to d them late at night, but it wouldn't be acceptable for a team member to do all their work at night, when no one else is working. Direct communication is important.
> If an employer felt it was a problem ... they need to find another deadline or another developer.
Be careful of this attitude nowadays. There's lots of people getting into software development these days, and there's lots that will work for less money than you. There's also a lot of managers that would love to pay someone less, regardless of their quality.
I know it's always been that way to some degree, but the problem seems to be growing exponentially as the years go on and more "developers" flood the market fresh out of school and racked with debt.
The reason I don't really need to be careful with that attitude is because it works both ways -- I wouldn't want to work for an employer that didn't agree. I'm also very clear when interviewing, which of course could cost me the position but that is a good thing (don't want to work there otherwise etc).
Any manager who believes they can staff a non-trivial project with fresh bootcamp grads instead of formally trained senior engineers deserves the seven kinds of Hell they are going to get.
> The notion that anyone in a modern software development job would care about the specific hours someone spends in a seat is ridiculous to me.
Sure, but I do expect that folks on my teams are spending about ⅓ of their lives—or 8 hours/day—working. I've been on teams where the majority of the team appear to spend about 6 hours a day actually in the office, and don't appear to be working (although of course they may be thinking/reading/learning) more than that.
That seems undesirable.
> You're either getting shit done or you're not
It's not a boolean; it's a rational. One gets so much quality stuff done over time. Those who produce more quality features over less time are more valuable than those who produce fewer, more broken features over more time.
> I've been on teams where the majority of the team appear to spend about 6 hours a day actually in the office, and don't appear to be working (although of course they may be thinking/reading/learning) more than that.
That seems undesirable.
This was sort of my point. If people don't want to work they'll find a way to not work regardless of whether they're in a seat.
> It's not a boolean; it's a rational. One gets so much quality stuff done over time. Those who produce more quality features over less time are more valuable than those who produce fewer, more broken features over more time.
Sure, but because of the above it can be difficult to tell whether two people who are equivalently productive are both working equivalently hard. At the end of the day, if they're delivering value proportional to their compensation, you're probably going to keep paying them.
"Sure, but I do expect that folks on my teams are spending about ⅓ of their lives—or 8 hours/day—working."
"Those who produce more quality features over less time are more valuable than those who produce fewer, more broken features over more time."
These two sentences directly contradict one another. If an employee is working 4 hour days and accomplishing more than their peers working 8 hour days, why do you expect them to spend 8 hours a day working—especially when you yourself have already said the former is more valuable?
In my experience, people who are able to get quality work done in shorter amounts of time typically produce lower-quality work when forced to work longer hours. Shouldn't you be encouraging this?
> > "Sure, but I do expect that folks on my teams are spending about ⅓ of their lives—or 8 hours/day—working." "Those who produce more quality features over less time are more valuable than those who produce fewer, more broken features over more time."
> These two sentences directly contradict one another.
Nope, not at all.
> If an employee is working 4 hour days and accomplishing more than their peers working 8 hour days, why do you expect them to spend 8 hours a day working—especially when you yourself have already said the former is more valuable?
Because time marches on, whether or not someone is working. The whole reason I want someone who's productive in a shorter amount of time is that once he's done producing one thing he can get started on something else.
I disagree. I think at least part of that is cultural (I'm in Australia), and part is about what "measuring actual results" really means.
The idea that you only measure results is a worse situation for the engineering team than measuring time.
If we only measure results, then a piece of work can be estimated to be "a week's work", and then the engineer is expected to deliver on that estimate and have it done by the end of the week, even if that means working overtime.
I don't want that. I want to be able to tell my team that, if they did a solid week's work on it, and it's not done then that means our estimates were out and we'll adjust the plan. But that is measuring time - they did a week's effort even though they didn't get the intended result.
The flip-side is that if something is estimated to be "a week's work" and they get it done in 3 days, then I don't expect them to take the next 2 days off. Rather, it means that our estimates were off (in the opposite direction) and we'll pick up some additional work this week.
To me, "taking 2 days off" and "only working 5 hour days" are essentially the same thing. So if I had a team member who told me "the task I was assigned for this week is actually pretty easy, so I decided to just finish at 2pm each day", then I'd consider that wildly inappropriate and tell them so.
In the same way, if a manager told an engineer "the task you were assigned this week is really hard, so you're probably going to need to work until 9pm each day" that would be wildly inappropriate.
I don't care very much what hours my team work, as long as it's effective - which includes having enough overlapping office time do have in depth technical discussions, and so they can provide mentoring and advice to junior team members (or get advice if they are the junior). But if someone is "coming late and going early" (direct quote from the article, but the emphasis is mine) then they're not doing the job that they're hired for, and we need to discuss why.
Most engineers aren't employed (paid) based solely on results - and don't want to be, they want to know that if they do their hours, then they've done the job. But conversely, if they haven't done their hours, then they haven't done their job.
I've yet to work at a job where my job was solely to "implement X". It is usually more along the lines of "apply 40 hours a week towards corporate goals."
My team has a feature and bug backlog half a mile long; I could clone myself and still not run out of work. And even if I did manage to close out the backlog, there's more work which could be done towards company goals.
> But the job is presumably not "being there from 9 to 5", it is to implement X. So why are you saying "they are not doing the job they are hired for"?
Most probably because measuring employees by results and not by hours usually means working overtime, not leaving early.
If an employer sees you leaving early while getting things done, why shouldn't she just give you more work?
To me, "taking 2 days off" and "only working 5 hour days" are essentially the same thing.
If they're the same thing, I guess you'd have no problem with a programmer who comes in and does 40 hours straight across 1.9 days, and takes the other 5.1 days off, right?
Not right, I guess. Because there's something wrong with your statement: it's based on the assumption that all hours are the equivalent. But they're not. The longer you're at work, the more mentally fatigued you get.
How many times have you worked on something in the evening, only to come back at it the next morning with a fresh mind and realize previous few hours of effort were a complete waste of time, and actually a different direction was needed?
You need to step back from something in order to get perspective, both literally and figuratively. When you're tired, nearing the end of the day, it's very easy for your higher brain function to go to sleep and to start bulldozing your way through problems using willpower alone. And you'll do a dreadful job.
Incorrect estimation is a completely different topic, because it's a different mechanism at work. Presenteeism is a symptom of management's inability to measure the productivity of an hour's labour during the day. An hour at 5pm might be only 10% as productive as an hour at 11am, or it could even be net negative. Nothing to do with estimates.
Personally I believe I have between 4 and 6 hours of productive programming labour in me per day. I'm only good for meetings and occasional discussion the rest of the time. I don't try and write any complex code past 4pm, because I know from experience I'll write it much better the next morning.
> So if I had a team member who told me "the task I was assigned for this week is actually pretty easy, so I decided to just finish at 2pm each day", then I'd consider that wildly inappropriate and tell them so.
Why is it inappropriate though? Employee happiness is also a part of compensation. Or at least it should be.
In a hypothetical situation I would gladly trade a few Ks off my salary for more flexible hours.
Well, it depends. If you have someone who is killing it and comes later and leaves early, who cares? If you have someone who is struggling and then also puts fewer hours in you've got a real problem. Unfortunately on my experience it's more often than not people who are already struggling who aren't putting the time in. To make that much worse people notice this and will perceive this as a unfair and demotivating situation. That fortunately though seems to work both ways. If someone is out a lot who is going great work, everyone is totally fine with it. This all makes for very unpleasant conversations and can undermine work moral on your team significantly.
> They looked up to me for leadership and that also meant defining what was and what was not allowed.
I'm guessing he's just paraphrasing what went on. People judging the person who came late and left early. The leader might know what is going on, but maybe the person itself keeps it for themselves. Then others might wonder why just one person gets so much leeway. This is basically lack of understanding and trust.
Secondly, he seems to indicate that sometimes people might come in late and leave early while he doesn't know at all why it is happening.
He's from the Netherlands so can relate a bit more (though I don't work in IT). There are loads of people who just do their time. Meaning, come in on time, follow their lunch time exactly, leave on time. This because their value their personal life and work is just something you do. If you have lots of such people, they won't understand why the rest doesn't do the same. Leading to resentment, etc.
Where I work someone has been taking loads of personal time for the last 3 years. Think of a minimum of 0.5 day/week and this excludes taking days off. Everyone understands why, and there's no issue. However understanding a manager might be, you also have to deal with the entire team as well as other teams. That you know why you did something or that your manager knows still might not be enough.
> If you judge coming in late or going early as inappropriate, as opposed to measuring actual results..
Surely the principle of charity dictates that the quoted passage be interpreted to mean "coming in late/leaving early to the extent that it damages productivity/morale".
I mean sure, the author might have meant that he judges people solely by their hours and not their results, but in context it doesn't seem likely.
I would disagree in that the author self admits he was a noob manager and observationally its not unusual for noob managers to focus very hard to what they can easily measure (butts in seat, timeclock hours, length of lunch...) because they haven't developed a skill of focusing on getting stuff they don't understand, done. I've had extremely weird conversations with new managers, they really can't evaluate anything outside of their old small picture beyond did you show up and are you in a good mood? For a few months an inexperienced noob sadly has nothing intelligent to say beyond "how bout that extra long lunch last thursday?". People pick up on the weirdness of adding trivia to the discussion but fail to notice the subtraction of all meat from the conversation, its all "he's so picky about calling in sick" not the equally true "holy cow I screwed up process 34B last week and expected to get called on the carpet about it, but all this guy talks about is sick days". As a corollary, if you're going to try something new that may explode, do it with a new boss, because if it explodes all he's going to understand is your timeclock hours and if you smile a lot, so you're off the hook.
Sometimes its a negative result of excessive stress or unrealistic goals. Bosses boss says do this two week in one week, boss says OK, inevitable fail, called on carpet, well dev A was sick with flu and dev B was five minutes late to work (LOL as if that matters). Next week the boom falls on sick days and being five minutes late. Sometimes bosses boss knows this is a stupid tactic and hopes the noob boss has a learning experience. I had a bosses boss who actually did that to me. I thought he was a complete ass for doing it, but punishing my guys was an effective way of stopping me from making dumb excuses in the future, so I haven't done that in 20+ years, at least not knowingly.
On a few rare occasions I've seen it as very poor communications. "Must be done before Tuesday" so nobody works on it over the weekend, when inexperienced boss really meant "Must be done ASAP like right now even if it is 2am on Saturday". Noob bosses need to learn to communicate. If you need all direct reports to show up for the staff meeting once a month with your boss on Wednesdays don't talk down to the employees and tell them to all show up at 8am every morning when they only really have to on rare occasion.
I've also seen incompetent middle managers enforce it on lower level managers to avoid certain discussions, as a punishment, essentially. I want someone else to take your job, so your direct reports are going to be screwed over until you fail and you are replaced. Or to appear more active and in touch, "I'm not just a pencil pushing idiot I have a really great plan to track who's late from lunch because I care because my eval says I need to care more, therefore you will support my dumb idea". Often there is nothing the lower level manager can do to improve those situations.
The above are personal anecdotes I've experienced in forays into lower level management. Other, perhaps better examples, do exist.
Such an approach to 'management' and workplace culture is likely to encourage and reward the perception of 'hard work' rather than actual performance and outcomes. This drives out high-performance, goal-oriented individual contributors who aim to work efficiently.
That said I wish all 'team leads' shared their thoughts as transparently online; that way prospective employees can more easily self-select and identify the companies and teams they wish to join.
Usually even if CEO, CTO (etc.) understands the logic behind it they still have this paranoid thought: What if my employee is actually slacking off instead of just being very efficient? How can I know? Maybe if I make everyone sit at their desk for 8 hours I can avoid being overrun by a bunch of slackers?
There's appropriate and inappropriate types of this: worked till midnight, absolutely flag it and come in late; left early yesterday, rocked in after WIP today without notification, probably not okay.
why? If i am still delivering what I must, and not missing any actual meetings, why do you care? Just the desire for the thrill of forcing your idea of what a workday is unto me?
Right, strict punctuality for punctuality's sake alone is counterproductive. If you want results, measure results. If you want butts in chairs, measure that. But don't confuse the two.
There are some highly talented developers with great interpersonal skills who just happen to have e.g. delayed sleep phase. They might leave "early" to have a normal evening with family or run errands, but then work more at night while they're awake with time to burn.
The compromise I've seen at many places is a set of core meeting hours, say from 10am to 4pm, where you're expected to be available for scheduled appts and expected to usually try to be around for unscheduled ones.
Of course, that doesn't accommodate people with severe delayed phase or whatnot, but often that stuff can either be worked out either on a team-by-team basis or arranged as part of the hire. Or maybe you only enforce the "scheduled" part, and put a "24 hours in advance minimum" on it to keep things humane. The important thing is to get team expectations in place.
What doesn't really work is "around whenever they feel like it," assuming there's any inter-team dependency at all. Even with an email SLA, that gets obstructive pretty quickly.
+1 this. I am one of these people and i work till 2am regularly and i wish companies understood this more. Thankfully my past 2 jobs have been very relaxed with me coming in to work late.
In my experience, 8 hours of face-to-face overlap actually makes me significantly less productive due to distractions. I can always get more done when it's more like 4-5, with 4-5 undistracted. Better yet is a remote work day. People can still contact each other via Slack, Mumble, Hangouts, etc.
> In my experience, 8 hours of face-to-face overlap actually makes me significantly less productive due to distractions.
In my own experience, those distractions are mostly due to open-plan and cubicle-farm offices. Given a proper one-man office, with a door, it's very easy to be productive.
If you wanna telecommute on some days, or need a modified schedule besides the standard 9-to-5, you should just arrange for that.
Having coworkers just showing up and leaving at any random time during the day I think messes with morale/vibe of the office. And as another commentor pointed out, communication. I like to know the general time-range I can find an employee to speak to. I'm old-school and still appreciate face-to-face time over online tools. If the expectation is set at the beginning that "Jane is a telecommuter Mon,Wed,Fri". Ok, that's fine. I don't like the idea of "Jane just shows up whenever she wants to, but she's getting her JIRA tickets done within the sprints and shows up to meetings".
Basically, while schedules definitely don't need to be rigid... they also shouldn't be fully impromptu either. If you're not telecommuting, I believe it is valuable to be physically around during office hours.
Hours are flexible on my team, so the hours someone is available for in-person discussion varies widely. It's never been a problem to send an email asking someone to stop by when they have a chance.
I absolutely agree that it is important to be around during office hours, especially to take advantage of mentoring opportunities. Taking the time to sit down with a more junior employee and help them figure out their next step is incredibly valuable. There doesn't need to be any rigidity to office hours to accomplish that though. I would be taken aback if a lead came to talk to me about work hours, unless I had become nocturnal.
> Having coworkers just showing up and leaving at any random time during the day I think messes with morale/vibe of the office.
That's a weird opinion to hold. You should change it. It hasn't been true in any company I've worked in for the past ~8 years.
> I don't like the idea of "Jane just shows up whenever she wants to, but she's getting her JIRA tickets done within the sprints and shows up to meetings".
This sounds like the perfect situation to be in, both for an employee and an employer.
Impromptu meetings are clearly a sign of disrespect, you sure got him there!
Reducing human interaction to schedules and timetables is one of the worse social diseases of this profession and I am personally very much done with playing nice with the people who wish to coddle them. Your coworkers are no less important than you are, and sometimes they have the temerity to need you for a human interaction at a time not in your calendar. I am certain you and your precious, all-self-important flow can deal with it.
Interrupting someone because you have a question is terrible for knowledge workers. If you can't wait long enough to ping them on IM or send an email, something is very wrong in your workflow.
Ahhh, premature optimisation! You've optimised for your time, but have you optimised for the best efficiency at the company level? Ok, so your precious flow doesn't get interrupted, but the person that had a question that needed your input now has to wait around until you deign to respond.
You know who doesn't work that way? Fabrice Bellard. If you're lucky enough to be his co-worker, you can sit down next to him and ask a question at any time, and he will stop what he's doing and answer you. Then he'll get back to work.
The attitude you expressed above (and it's far from uncommon here on HN) is just an example of developers wanting to be treated like special snowflakes. I do not believe this is a desirable trait for someone working in a company.
This attitude tends to stem from having been managed by non-engineers. Spend a year or two working for someone who interrupts you for updates every 15-30 minutes, and you get extremely protective of your focus. You also become aware that the cost of interruption is relatively high. Generally, developers don't want to be special snowflakes. We want to be allowed to actually get our work done in a reasonably time-efficient manner.
Perhaps that is not a desirable trait for someone working in a company.
Also, I submit that if your company is larger than a couple dozen people and there are many questions that cannot be answered by more than one person, then your company has significant compartmentalization problems.
Thank you for expressing exactly what's going on in my mind.
I hate being interrupted, we all do, even working as a cashier in McDonalds. But the idea that a special branch of people SHAN'T be interrupted is snowflake treatment.
I already feel privileged over other employees in my company for having flexible workhours (felt sick yesterday evening, sent a text at 1am and got at work around 2pm today despite a production deployment being scheduled for 5pm), now if suddenly MY time is more important than anyone else's, I'm not an engineer, I'm a snowflake in an ivory tower.
If my junior intern is being delayed in her work because I can't answer her questions, I'm not her manager, I am the idiot who is delaying our team's output.
She is one meter to my right, unless I tell her "Sorry I'm trying to think of something give me five minutes", I want her and ANYONE who joins my team to ask me any and all questions, otherwise A) I've done a bad job showing my team they can communicate properly with me B) I've done a bad job managing them because I am slowing them down.
> Interrupting someone because you have a question is terrible for knowledge workers.
A couple people having the sheer clanging temerity to ask me a question doesn't bother me a bit, and I'm not special. I've learned to work in the kind of comprehensible chunks that allow me to be useful to other people, though, because being a multiplier is vastly more valuable (and pays a lot more) than being an adder.
Meeting for everything is bad as well. I don't like email/chat and I consider that wastes lot more time for miniscule task. Want to cost of something. Pick the phone and ask.(Check if the person is free or busy in calendar). I appreciate the following. Physical/Direct -> Phone -> eChat -> Email. makes thing faster
I would consider that you add a step before making a phone call or going and tapping somebody on the shoulder.
The thing that most threatens my zone is when the headphones need to come out. The _only_ exception is a simple yes/no, such as, "hey, want a coffee from Starbucks?" Anything bigger, whether a phone call or tap on the shoulder can really kill my session or workday. I'm talking your five minute conversation costing an hour or more of wasted time.
What do I recommend? Message me first and say "hey are you free to chat?"
> Anything bigger, whether a phone call or tap on the shoulder can really kill my session or workday.
This is so manifestly out of proportion to the disruption that I would (gently, as I am not unsympathetic, and personally I have no problem with IM, though emails can go to hell because developers generally ignore them) call it the kind of personal problem I'd hope you could work on and improve rather than imposing that on everybody around you who expect generally reasonable parameters of human interaction.
Working as a remote ops guy setting up a startup's systems, my quality of work dramatically improved when I joined the team in person, because I got to hear the various little things that people don't mention in online chat, and was able to account for them. This idea that all communication is entirely possible to be held within scheduled meetings is incredibly naive.
If you work in complete isolation, sure, but that's not reality for most. There are times when you need to communicate with others, in-person, beyond scheduled meetings. What do you do when that person is not in yet? You wait. What about if they left early?
If every single person in the office decided on a custom, non-overlapping schedule, how productive do you think that would be? Unless you're open to answering e-mails and IMs at home and on the go at all hours.
Yea I was working for a company for a very short period which was focused on autonomy. The texts, emails, and slack messages as early as 7, as late as midnight, on saturday, on sunday. It drove me crazy to say the least as someone who, ironicly enough, valued his own autonomy very greatly.
Think beyond yourself. In a team environment, there are times at which other team members will need to communicate with you to get their work done. If you're working on a different, arbitrary schedule, you can impede your team members.
If you want true flexibility and control over your schedule, the best option is to become a freelancer or consultant. But keep in mind that in many cases your clients will also have expectations around your schedule and availability.
I can't see that being too much of a problem if you use the concept of "core hours" during which everyone should be available. Say, make core hours be 10am to 4pm. For anything else, email should be sufficient, imo.
Exactly. Every time I see this micromanagement culture I'm reminded that this is actually the norm and I should be grateful for working in a sane place, where I'm not treated like a child.
"Not missing any actual meretings". There will be meetings you are not a core participant in but it would still be beneficial for you to be present. Will you leave the planners wondering if you will be in at all? Vs having core hours where there's a good guarantee everyone necessary is in barring vacation/unplanned leave?
> They looked up to me for leadership and that also meant defining what was and what was not allowed. Of course, this is easy when somebody makes a remark that couldn’t pass or does wildly inappropriate acts such as coming in late and/or leaving very early. The hard part was when this coming late and going early was done for a good reason, such as a sick spouse or child.
How is this the hard part? They have a valid excuse. If they work remotely or get their work done, it's not a problem.
Unfortunately there exists a messy side of company culture in which perception (by peers and management) impacts morale and performance. In a utopian company, all employees are judged purely on their productivity and have unilateral say in their working conditions. Unfortunately our world is filled with people and their pesky emotions. People get upset when they perceive unfair treatment, and things like "good reason" and "productivity" can be so subjective.
This is a matter of nurturing a good team culture. Culture is hard.
Agreed. I don't even consider coming in late and leaving early inappropriate at all. The office is there to help you get your work done and communicate with others on the team. If you are able to accomplish that without being in the office 9-5 then that shouldn't be a problem to anyone.
This is a tangent but, as a father I've always felt the sick child/spouse excuses were dumb in the same way that smokers were allowed to take extra 15 minute breaks at one of my jobs. Shouldn't the presence or absence of a family be irrelevant to your employment rules?
Life doesn't actually stop when you clock in. I think it's reasonable from a business perspective to realize your resources don't work 100% for you 100% of the time.
However, if the company really want to disallow people missing time here and there to deal with family, I really hope they'd never ever ever consider asking them to work before 9, after 5, or on the weekends no matter how high priority the business tasks are. I hope they're the kind of employer that turns off email at 5.
For me, the time I take to deal with my personal responsibilities at work is more than balanced by the time I take to help my employers out outside the hours of 9 to 5.
> I think it's reasonable from a business perspective to realize your resources don't work 100% for you 100% of the time.
I also recommend barring the use of the word "resource" when you specifically mean "person". Capex, opex, machines, buildings, presses, are all resources. Allowing your leaders to talk about people as being "resources" biases them to think in a certain way (or at least risks that).
It is unfortunate that in the phrase "human resources", "human" is an adjective... ;)
Hmm, I don't really think its off by much, especially in Westernized nations where practically every thing is governed by contracts, regulations and legalese. And especially at a management level. You allocate resources to accomplish tasks. If you have a C++ developer, that's a resource. Resource X costs Y and produces Z could be applied to JetBrains licenses or people. Maintence for licenses is quite simple requiring updated payment information, maintence for people is a lot less clear cut and requires communication, and lots of ambiguous judgement calls. It's stale but I'm not sure there's a better word to fit in its place.
Denotation of people on salary as a "resource" is correct, and I'm even OK with including people in a collective set of varied types of resources. "We just don't have the resources to pursue all possible ideas" and the like is fine.
I'm recommending a terminology change to always call people "people" as it biases your leaders to think of them as special and different from licenses, machines, money, and black boxes. (It's not my idea originally, but I've seen it play out at my company and believe it to be helpful.)
Pretty much this. I'm fortunate to work at a place where I'm paid to get a job done, and how/where/when I do that is largely up to my discretion because they treat me like the responsible adult I am.
If I occasionally work some nights or over a weekend? I might take a day or two off to avoid burnout (while making sure there is appropriate coverage in place). Likewise, if I need to have a contractor come over or something, I'll just work from home for that period of time. If I need to take care of personal things during the week where I can't work during that time, I just take care of it after hours or on the weekend as needed.
That said, I've worked at places with strict 9-5:30 (but really it is 6:30+ because of the workload) and they seem to want to have their cake and eat it too in terms of getting you in at a strict start time, get lots of extra hours + weekend time when needed, and then hit you with limited vacation time and pushback when you want to take a comp day. Sorry--doesn't work that way. Maybe when I was young and stupid, but at this point in my career I've lost all tolerance for that. Fortunately it seems many companies are starting to wise up and be fair about it.
The dumb thing that I see is that employers sometimes don't give childless employees the same leeway. Like I had an employer who let mom's leave for their kids, but gave me a hard time when I left to go to a hospital after my brother was in a terrible car accident.
But just plain forbidding dealing with sick children is a horrific policy. Unless you want all your family employees to leave or hate you.
This is why I brought this up. I had the same situation where the only person on the team who had a "valid excuse" was the one who had to take kids to school in the morning. Other people on the team felt they were required to do more work because they had chosen not to have kids. Any method of defining what constitutes a valid excuse is likely to step on someone's toes.
Not in this case no, but even in the case where they were asked to stay late I would still find the idea that they had special priviledges to reconfigure their schedule unfair. As a parent myself I just believe I'm not entitled to special treatment at work because of the life choices I've made to have kids.
Was there complete transparency on salary there? I mean - that person might have made a deal with your employer to take a lower salary in return for that privilege. Either explicitly or simply by not getting the same raise as they would otherwise. I find it a bit peculiar that people concern themselves with these things, but have no problem with differential in pay.
I wonder how much of these anecdotes are a natural outcome of human discomfort with a situation?
Maybe your boss was just uncomfortable and feeling bad/empathetic with your brother's condition and didn't know how to handle you, so handled you awkwardly and stiffly, which you internalize as "a hard time".
If someone gave you an actual hard time over something like that, I don't want to get all internet badass here, but "you have my address; please send my last check there" might be the most appropriate response...
(I'm not in any way discounting the certainty that there are asshole employers out there, and the possibility that you worked for one.)
I had already left and just sent an email back saying "Well I already left and I'll be in Duluth for a while. I'll talk to you when I get back." I think the boss realized he was being a dick because it was never mentioned again. I think you might be right, discomfort plus not knowing how to handle the situation.
He survived the crash but is quadriplegic now. He was very lucky though, his two best friends died.
Back in the bad old days... when men went to the office and women stayed home, you could expect that a working mans family issues stayed at home. Now with more two worker families and single parent families, it's just not the case.
What is important for morale is that your single workers not feel like they are the ones covering for Mr and Mrs Familyman without some quid pro quo.
I think that's what I was getting at. The whole concept of a "valid excuse" seems arbitrary to me. I worked at a place that had regular office hours and one of the people on the team was regularly late because he had to drop his daughter off at school. He was the only person on the team who had what was considered a "valid excuse" to be late. The single people strongly resented that because they felt they were being forced to work harder for the same pay since they made different life choices.
There's just something so hilarious about the idea of a single person resenting a married-with-children person on the basis of the amount of work they have to do.
I am all in favor of accomodating people, but this is some kind of bull, man. You agreed to do a job. The childless person did, too. Your kids aren't work, and they don't factor in, and I know you know that. Having additional work pushed on the childless person (and I've seen it happen, though never to me) because they don't have kids and "can handle it" is straight-up unfair, unless they're being properly compensated.
One perspective is that bringing up children is in the interest of society as a whole. In giving a bit more leeway to parents, it's really all of us who benefit. Or more to the point - it is reasonable to assume that all (or most) the single people will eventually become parents hem selves, and they will then get the same benefits, since it's an ingrained part of the culture.
I was primarily commenting on the perception that parents are having a gay old time playing hooky when they have to take time with parenting issues. Of course all people should have reasonable accommodations allowed to them whether they have kids or not.
But you have to be careful of judging "reasonable" through the eyes of single twenty-something (or any single opinionated person for that matter). In the end you may restrict yourself to young unencumbered people who can afford to live their life according to a universal office schedule. But this can be harmful when you lose out on different experience and abilities. It's not necessarily true that the person working 12 hours every day is outperforming the 8 hour a day clock puncher. If you optimize for butt-in-seat time rather than overall productivity don't be surprised when you have substandard results.
I work three days a week, man, and actively resist working more. I am about as far from the type to live according to a universal office schedule as possible. What I'm saying still stands: "because I have kids" for a parent is no more of a valid excuse than "I have a thing I want to do" for anybody else. They are time you are not doing work you have (in theory) agreed to do, and to an employer they should be the same thing.
Well first of all you are violently agreeing with me if you go back and read the second sentence of my last reply.
But to your last point, things you have to do to take care of your kids are emphatically not the same as "I have a thing I want to do". These things are all on a continuum, but kids are far more demanding than hobbies. I'm guessing you don't have kids to make such an equation.
> things you have to do to take care of your kids are emphatically not the same as "I have a thing I want to do"
Nope, wrong, full stop. Your kids are important to you. They take time to deal with. My side interests are important to me. They take time to deal with. From the perspective of the business, there is no meaningful difference.
I don't have kids. I don't need to have kids to understand that your parental activities are not more demanding than, say, building a startup or developing a video game. But thanks for trotting out that tired chestnut. I'm more annoyed with your sneering attitude towards the childless than anything. You should stop.
Nope, wrong, full stop, truly spoken like someone with no kids and no idea of the reality of managing people.
Excuses are obviously on a continuum of validity that has nothing to do with kids vs not kids. For instance, if you have to go to the doctor that is a more valid excuse than you want to go to an amusement park and ride a roller coaster. To suggest all things are equal in terms of valid excuses is ridiculous on its face. As a manager you have to recognize that people are humans and that stuff is complicated. With your attitude you will not be able to retain any employees but the most desperate to retain a job.
> The single people strongly resented that because they felt they were being forced to work harder for the same pay since they made different life choices.
That's funny, because your life choices always determine how hard you have to work for the same pay in every other context, so why not this one? For instance, try making the same income after committing some crimes.
They're not dumb in the sense that you have a distraction that you (or your SO) simply must deal with. It's not like it's optional to go pickup your kid from daycare or school if they're sending him home.
If you're doing repetitive assembly-line type work, maybe you worry about an excessive smoke break pattern. If you're doing creative and novel work (as most programming is), don't sweat the smoke breaks. Sweat the overall output and contribution maybe, but I don't find time-at-keyboard to be nearly linear with output.
(Context: I'm a non-smoking father of two, aged 4 and 6.)
It is possible that smoke breaks boost productivity for knowledge workers like programmers. Not so much the smoking part (which may have some effect itself), but simply taking a break could be benificial to total productivity.
As long as it is also socially acceptable that non-smokers take various 15min breaks during the day and talk about nothing.
I once worked at a place where smokers took various breaks but it was not acceptable to just idle around. IMO nowadays I just see it as weak management, not being able to determine and/or say to a person that they're taking way too many breaks.
Also you can pretty much either accomodate or run the risk they'll just leave to somewhere more understanding. Do you want to be rehiring the same position every 2-3 years and in the meantime making people unimaginably hostile to you ('no I want you to ignore your children for an extra hour I probably got for free elsewhere anyway').
I suppose you could argue that, and a workplace with that mindset could certainly work for some people. As someone who values my family, though, that's not somewhere that I would choose to work. I think you'd also find that most people will not be flexible for their employers when the employers don't expend the same courtesy. In the end, we're all humans, most of us don't operate in a social vacuum, and I wouldn't want to work for someone who fails to understand or respect that.
Take a 15 minute break yourself. There's objective evidence that getting up and going walkabout every for fifteen minutes every hour or two is good for you. I mean, it's not like you stop working right? The break and the distance can really help.
If you happen to smoke (or are gregarious, or can pretend to be) you'll also meet everyone (for values implying a random distribution of all people working at your company from AP to exec) outside. You might be surprised what you can learn.
Can depend on where you live. If you have moved to a new area for a job and have no friends or relatives within 6 hours. Your wife is struck down with a nasty illness and is barely able to get out of bed in order to get to the toilet and you have a chlid who needs taken care of / taken to nursery / school etc
Quite so. My youngest is now 24, but I remember those days. I remember thinking that "I thought the idea was that we work together to get this stuff done," and that if the company decided that its interests were more important that the health of my family, then we were going to part company before long.
Now we have "work-life balance", which is a red flag to me, just like hotels putting "quality" in their name, in case you don't notice...
This sounds like an engineering manager role, especially since it involves hiring/firing and setting salaries.
Why is it called "lead developer"? The cynic in me thinks it's to make it more palatable to promote engineers who still want to code. But as this post details, that's the wrong expectation.
OP sounds like he works for a startup, where he's given the title of a Lead Developer, but is expected to perform the role of an Engineering Manager and even some CTO duties. In addition to hiring/salaries, also worrying about software licenses? This is not the description of a lead developer.
I totally agree. Lead developers write code, also remove real, tangible and hard roadblocks in the code for the team... this sounds like a bureaucratic nightmare. I think he was turned into a manager without him realizing it.
In my experience in small companies "Lead Developer" usually means "the person who wrote all of our initial software and still does some programming while keeping track of our code base in general". I.e. something between a retired programmer, a software architect and a CTO.
I did have to hire people and in the current market that was a very hard task. Especially so when the company in question is not a sexy startup, nor is the stuff they’re working on amazeballs, nor is the market that they’re in one that attracts a lot of people. It took me a lot of time interviewing people and even offering them a job (with a pretty good offer, mind you) only for them to choose another company.
I totally agree that the role seems like way more of a manager than a developer, so "lead developer" is a strange title. Of course titles are pretty strange and generally not very "portable" to begin with.
It's a normal thing to call it that in the Netherlands, where the author (judging by the name and the mention of him organizing AmsterdamPHP) is from.
Also, in IT it's normal to put people in leadership roles without any training or preparation, which in any other field is rightfully considered absolutely insane. FFS even McDonalds doesn't just take the best burger flipper one day and tells him 'yeah so as of tomorrow, you're the boss, good luck'.
Some of the things listed in this article are more of a manager's role instead of a lead developer's role. With that being said, every company defines the lead developer role a bit differently.
For anyone that is interested in a lead developer role, you need to understand that there will be less coding. The amount of less coding is dependent on the company. Some companies expect 60% coding out of you and some companies expect a maximum of 10% coding out of you. If part of your tasks include delegating work to your coworkers… be prepared to give up the fun stuff. I often find myself doing the boring stuff so that the people that work for me can enjoy what they do. I personally enjoy the team lead role, but if you are interested in moving in to a team lead role, you should really understand what the company’s expectations are… because every company has different expectations for that role.
Lead here: My own experience with various companies has been that they expect 100% with the additional management work on top (like a cherry). You end up delegating a lot of things and get tired quickly. I'm currently working on re adjusting this issue and it's going much better. Still is a lot of work with little benefit. Except for the ability to help others grow into better devs. I love that part.
I've worked in an organization where leads were expected to do all that a lead is generally supposed to do AND also have sprint velocity (work throughput) equal to or higher than senior engineers on the team. I always thought this was absolutely bonkers, but at least now I know I'm not crazy
I have been told by people that I'm a "natural leader", perhaps not to the extent of the author. But I am just uninterested in all this stuff, I'd have to be paid double or something.
I'm in the same boat. I've had management at a handful of companies discuss me taking on more than my Senior Developer role, for an extra $10-20k. That much stress does not warrant only a few years' worth of raises. Double my salary well above $150k+ (I'm not in the US) and I'd consider it. They'll have to pry my precious code from my cold, dead hands. I'm in my early 30s now; perhaps my preference will change as I approach my 40s, but for now I'd rather be a rock star in my field than be just another manager whose team hates him because he has no real control to change the company's politics.
IMO manager = make more money but put in way more time. Meaning, deal with the questions from higher management, prepare all the various performance meetings, etc. Especially sudden highly important tasks are fun. Or announcements that happen on e.g. Monday and you get your information Friday late. This leading to having to review everything during the weekend.
It seems some people care more about the total salary than what they earn vs time invested.
PS: Regarding your team hating you: Decide for yourself how you manage. I prefer the honest types who just say "company decided and we just have to deal with it". If you start pretending you totally agree with things you'll not be able to give good answers to the various questions and people will think that you have no clue.
Choosing to take on management roles doesn't mean someone cares more about total salary than time earned. They probably just care more about team culture and mentorship.
I suspect common reasons for taking on a low-level management role include a) developer burn-out, time to move up and not have to code all the time; b) desire for more power (whether for egotistical reasons or in the hope of effecting positive change in a position of power); and c) a stepping stone to further levels of management where the salary upgrade actually becomes tangible.
I don't disdain competent developers who move up, I just personally don't understand it - yet. I imagine the time will come where I've had my fill of programming. Even if I don't burn out, I expect I will reach that age where I begin to feel that younger developers and management are dismissive of my abilities, and it will be the only escape into a role where I can earn back some respect. :)
A "natural leader" who doesn't really want it will often strike people as a great leader. I bet that when you get shoved into such a spot, you do your best to get it over with quickly and efficiently.
There is no leadership in Tech / Dev. (Don't worry there is much in other parts of the business world and certainly not in the banking / finance realm.) That's why they invented Agile. The business side needed to make sure the tech side was "doing" what they could quantify.
Sure you can read from a book, but leadership is one of the few characteristics that has to be experienced in combination with self evaluation, in what this author is doing.
Financial management, hiring/firing, KPIs, 360 reviews - none of these things are lead developer responsibilities imo. That's management work. I prefer the two be separated. In my experience, the last person you want leading development is a manager or, worse yet, a good lead developer that is shoe-horned (probably unwillingly) in to management. Maybe that will be something else he learns soon :)
Do you know of more initiatives like PHPmentoring? (which he mentions in the article). I like knowing about all the options :)
Thanks
P.S.
While it is helpful to see suggestions on how his perspective could still be improved its also good to know which of the things he said you consider good advice. I feel like people have a tendency to only speak out when they see flaws.
Very insightful! all things I'm eager to tackle when I land a lead position. I don't mind writing less code if it means I can facilitate larger movements.
Although as others have noted this has a lot of management roles mixed in as well, which is more than what a lead dev might typically do.
Here are two quick examples where I see this happen often. Let's say you're a vendor deploying software at an organization, and one or more people that work at your client organization originally wanted to write their own solution for this software, and their bosses overrode their wishes, and now they're forced to help implement your software. You need to use those disenfranchised IT people as part of your team to do the implementation, but they'd like to see the project fail, because they told their manager they could do it better themselves. Other variations of this occur whenever someone doesn't get their way, and is forced to go implement things a different way -- now any delays that happen may demonstrate their sage wisdom in not wanting to do it this way.
I've also seen variations on this same theme where a company is working on a product that does what we're implementing, but it's not ready yet. Then a year down the road, when we're doing the final rollout, their product is almost ready, so now they'd like to see us fail. And suddenly the alliance falls apart. Over the last 30 years working in IT, I've seen something like 20-30 variations on this theme.
Lots of times you need to work with people who really want to see your project fail. This came as a huge surprise to me, but I think any senior person should be careful and on the lookout. It's often a significant project risk, and almost always overlooked.