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.
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.
>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.
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.)
> 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.
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.
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?
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.
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.
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.
> 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?
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.
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.
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.
[+] [-] unoti|10 years ago|reply
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.
[+] [-] stevoski|10 years ago|reply
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.
[+] [-] timv|10 years ago|reply
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.
[+] [-] fit2rule|10 years ago|reply
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.
[+] [-] lfowles|10 years ago|reply
[+] [-] sokoloff|10 years ago|reply
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.)
[+] [-] jlg23|10 years ago|reply
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.
[+] [-] obrero|10 years ago|reply
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.
[+] [-] hga|10 years ago|reply
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).
[+] [-] dmitrygr|10 years ago|reply
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.
[+] [-] jsolson|10 years ago|reply
[+] [-] timv|10 years ago|reply
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.
[+] [-] ajmurmann|10 years ago|reply
[+] [-] abalone|10 years ago|reply
[+] [-] bkor|10 years ago|reply
> 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.
[+] [-] fenomas|10 years ago|reply
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.
[+] [-] vincentbarr|10 years ago|reply
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.
[+] [-] odiroot|10 years ago|reply
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?
[+] [-] mbostleman|10 years ago|reply
[+] [-] grrowl|10 years ago|reply
[+] [-] utuxia|10 years ago|reply
[+] [-] vellum|10 years ago|reply
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.
[+] [-] dkokelley|10 years ago|reply
This is a matter of nurturing a good team culture. Culture is hard.
[+] [-] sintaxi|10 years ago|reply
[+] [-] dangero|10 years ago|reply
[+] [-] julian_t|10 years ago|reply
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...
[+] [-] abalone|10 years ago|reply
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.
[+] [-] developer1|10 years ago|reply
[+] [-] roel_v|10 years ago|reply
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'.
[+] [-] codingdave|10 years ago|reply
[+] [-] krallja|10 years ago|reply
[+] [-] vblord|10 years ago|reply
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.
[+] [-] bliti|10 years ago|reply
[+] [-] trustfundbaby|10 years ago|reply
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
[+] [-] draw_down|10 years ago|reply
[+] [-] developer1|10 years ago|reply
[+] [-] bobbles|10 years ago|reply
[+] [-] Kalium|10 years ago|reply
[+] [-] chad_strategic|10 years ago|reply
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...
[+] [-] mbostleman|10 years ago|reply
[+] [-] openfuture|10 years ago|reply
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.
[+] [-] meesterdude|10 years ago|reply
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.
[+] [-] MrGando|10 years ago|reply
[+] [-] lox|10 years ago|reply
[+] [-] daxfohl|10 years ago|reply
[+] [-] unknown|10 years ago|reply
[deleted]