Things I was unprepared for as a lead developer
dev-human.com
dev-human.com
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.
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.)
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.
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...
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.
It's when they covertly run counter to that that the real trouble starts.
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?
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.
AKA Everything You Need To Know To Manipulate People.
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.
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.
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.
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.
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.
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]
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.
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.
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.
Why does a non-contractual relationship change things? Are you applying the Copenhagen theory of ethics or something?
http://blog.jaibot.com/the-copenhagen-interpretation-of-ethi...
Also, why dont the workers who became dependent on a company deserve responsibility for that action?
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.
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.
Stats: http://www.maxroser.com/economic-world-history-in-one-chart/ http://ourworldindata.org/data/growth-and-distribution-of-pr...
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.
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.
http://www.maxroser.com/economic-world-history-in-one-chart/ http://ourworldindata.org/data/growth-and-distribution-of-pr...
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.
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 don't know the Thailand govt well, but India has similar laws and is explicitly racist about them.
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.
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.
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.
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).
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.
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.
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.
It has the virtue of assuring that we are all available in person to one another, which is actually pretty valuable.
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.
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.
a.k.a you like to interrupt people on a whim. Show some respect and just schedule a meeting.
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.
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?"
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.
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.
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.
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.
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.
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.
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.
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.
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.
That didn't last long.
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.
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.
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.
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.
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?
> 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.
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.
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.
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?
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.
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.
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.
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.
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.
> 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.
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?
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.
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.
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.)
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.
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 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... ;)
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.)
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.
But just plain forbidding dealing with sick children is a horrific policy. Unless you want all your family employees to leave or hate you.
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.)
(Hope your brother is now OK.)
He survived the crash but is quadriplegic now. He was very lucky though, his two best friends died.
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.
Raising immigration quotas does the same thing and costs less.
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.
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.
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.
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.
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.
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.
This is a matter of nurturing a good team culture. Culture is hard.
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...
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.
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.
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'.
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.
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
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.
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. :)
Object Oriented leadership? OOL
Human Emotion Design Patterns.
Functional Emotions...
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.
Real leaders don't shy away from a challenge...
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.
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.