How can I encourage a culture of punctuality in a software company?

Question

As a new technical lead in a new company, what are some additional strategies to employ to change the culture of the development team so that people show up at the time that I've requested?

TLDR: My team doesn't show up on time. I've tried to compel them and it isn't working.

Background Data:

1. Small company, 30 employees, 5 members of my team.
2. The previous lead is still on staff as a regular developer.
3. The culture prior to my arrival was one of informality with no set boundaries or core hours. This culture was not challenged by the corporate leaders. Most people on the team would show up between 10:30 and 11:00 because of this.
4. Other departments, due to the nature of their work, have set start times of either 8 or 9.

This discrepancy and unpredictability causes a lot of angst between my department and other departments. As such, I sat the team down and specified a 'no later than' time of 9:30. I explained my reasoning and I explained the benefits of such a scheme and the negatives of the current scheme. It was a long and contentious conversation and 3 of the 5 people on the team were quite displeased.

Needless to say, people aren't showing up on time (and 9:35 is not on time.)

I've scheduled our daily standup meeting at 9:30 as an added motivator. Knowing that it takes a little bit of time to transition start times (with commute, etc...) I initially would wait to begin the meeting until everyone showed up, but now I just start the meeting (and often finish the meeting) with whomever is present. That seems to not be making a difference either and it's making the team less cohesive.

Conversations on an individual and group basis yield the same results as the original conversation (i.e. they don't see the value, think I'm taking away a perk of the job, etc...)

I have the full support and backing of the senior management team and am empowered to employ whatever devices I feel appropriate to get this taken care of.

My current next step is to send someone home and make them take the day off. Is that too drastic? Are there alternative strategies that I'm overlooking that could help me solve this problem?

Edit based on questions in Jarrod's answer

How new of a technical lead? 6 months, at this company, at the time of this question.

Why are you imposing purely non-technical managerial policies? It is in the scope of my position as defined by executive management.

What are your management credentials? 10 years experience as a technical lead. No formal education or certification in anything managerial.

What previous personnel management experience do you have? I have been a technical lead for 10 years. I've been responsible for hiring/firing/interviewing/reviewing/leading/building a few different technical teams.

Have you earned the respect of the team in a technical manner? Yes

Have you earned the respect of the team in a managerial manner? I was interviewed for technical and managerial ability by the team. I was clear and straightforward about how I like to run technical teams and how I like to run projects (with the obvious caveat that that is just a starting point and culture and personnel ultimately influence where I land.) There are many things, from a managerial perspective, that the team is quite happy with.

Did the previous technical lead step down? Yes.

Was the previous technical lead demoted? No. It was his request.

Was the previous technical lead effective? For a time. But, growth of the company and the codebase made his style ineffective.

Does the majority of the existing team have a more personal relationship with the previous technical lead? Yes.

Is the previous technical lead effectively still in charge? No.

Then [the previous culture of informality with no set boundaries] must have been working? It worked for a time, when the company was still a startup. It has grown and evolved well beyond the startup phase and, due to that growth, is not nearly as effective as it once was. Especially as other departments have introduced a bit more formality and predictability.

Was the team successful in delivering useful products when promised? At the beginning. But, as the company and the product grew, quality and delivery times slipped significantly.

Doesn't sound like you even considered or explored some kind of compromise with your team or the external teams based on their negative feed back. Did you? Of course I have, I'm not a rookie. The fact of the matter is, I respect the fact that the rest of the company works in an inflexible box due to the nature of their responsibilities. The team was unwilling to compromise on their flex time and, in many cases, the other departments are unable to compromise. I have also addressed the negative feedback specifically with the other departments and implemented a number of things to make things better. One of the big benefits of this change was to improve predictability and change perceptions.

Answer 1

The best motivating factor is trust. Team unity is of ultimate importance in accomplishing your goals. Rule cultures are bred of distrust, and sticks and prods to enforce rules will only further erode trust from your team.

Rather than being concerned over exact times and informal cultures, try figuring out what the intrinsic values are.

• Does 9:30 (or any arbitrary time) really matter? Or is it that your team needs to make sure they are not hindering the work of other teams by their absence?

• Does 5 minutes make a difference? Or is it most important that all members join in the daily standup?

• Is informality a problem? Or is flexibility a benefit?

I would dig at the core of the issue, which is that your team hasn't bought into the idea. See where the disconnect is, but avoid creating a rules culture. Sending them home for being late (a disciplinary tactic you'd find in an elementary school) will lead your team to believe you see them as children who can't be trusted.

Answer 2

You're not dealing with a manufacturing process where everyone must show up at exactly 9:30am, when the whistle blows, so they can begin the mind-numbing task of assembling the same little plastic widgets repeatedly, until the whistle blows again, and the mind-numbed staff make their way out to the local bar for happy hour.

My team doesn't show up on time. I've tried to compel them and it isn't working.

Forcing smart people never works. You need to remember that you're dealing with highly educated, smart, creative people who are good at solving complex, abstract, and unique problems. These people, at least the really good ones, will never just blindly follow orders.

As for the other workers in the company, if they didn't have the foresight to spend nights and weekends beating their heads against a Computer Science book trying to understand formal logic so they could enjoy the perks of being a developer, then frankly, that's their problem. Change careers. They made the choice to study something different and enter a career that involved shift work. So they must now deal with it.

You mentioned that you're a new team lead. Stepping into a new position like this is challenging and stressful as you're not sure how to gain respect of the team and also be a good leader. This comes with experience, and it's common for inexperienced new team leads to attempt to "compel" or force people to do things their way. This is not leadership.

Developers don't need a manager; instead, they need a leader. Great leaders inspire others to do great things, and this is your opportunity to lead your team to greatness rather than dictate it into despair.

So, with what we know about developers and their problem solving abilities, have you considered presenting this problem to the development team and letting them come up with a plan to solve the problem?

Research shows that people are more likely to commit when they have participated in determining what the solution will be rather than have that solution told to them, and this is especially true with knowledge workers.

So, present this as a challenge to the team and see what they come up with. Your team may surprise you! While the plan may not be perfect nor will it be exactly what you envisioned, I guarantee you that there is middle ground somewhere that will make both the development team happy, as well as solve the actual problem.

For inspiration, please see Seth Godin's Interview on the Difference Between Leadership and Management. I highly recommend that anyone and everyone in a leadership capacity watch this short interview.

Answer 3

It's been my experience that knowledge workers don't like being dictated to about policies for which they see no purpose. You do state a purpose, but the employees you are managing seem to think it is not a good one. Further, there are probably alternatives that you have not considered, and given what sounds like an issue being "dictated from above," your employees may either not have thought of them, do not feel comfortable proposing them, or feel that they would simply be shot down.

If the only reason you are implementing the policy is because of tension with people in other departments, it's your job to manage that tension so that your people can work most effectively. I don't think that's the only reason, though. For example, what if a developer is needed to fix an urgent production issue that happens at 8:00 or 9:00 or whatever other time? However, it is unlikely that you need all your developers present to fix that issue. What if you had a rotating (unless someone volunteers) "early" schedule, so that each developer takes a turn being required to be there at 8:00 (or 9:00, etc.)? That solution seems more likely to satisfy both the business needs and the desires of your employees. Everyone "shares the pain" (or inflicts it on someone who doesn't mind it). People can come in and work most of the time when they feel they would be most productive. This is just one possibility, but it may generate discussion with your employees about how to solve the real problems and satisfy everyone's interests here.

If you choose to go down the more disciplinary route, and the "start time" issue truly is important to your developers, you will lose your good ones to other employment. Your employees are likely to feel insecure in their jobs (what if some real emergency actually happens one day to make someone late?). Further, this can be seen as a shift in management in the wrong direction (from your employees' perspective), since they did previously have experience working under someone else.

It's up to you, of course, but I would urge you to take a step back and try harder to see the situation from your employees' perspective. You have a job to do, of course, but I think there are solutions that better satisfy everyone's interests than the one you are proposing.

Answer 4

The precise answer to your question is to fire and replace somebody who doesn't get the message and then fire anybody else who doesn't get the message.

I don't expect this would help your career or your company's development goals but you've decided this is the issue and it appears there's no convincing you otherwise. So that's how to do it.

More constructively, I would suggest you consider the following:

• Your devs had flex time. Now you want to take it away

It doesn't matter whether it's an official benefit in some written policy or not. It's a de facto policy and a part of the established culture. People's lives and schedules have been established around these hours. And for devs like myself, who much prefer dodging rush hour and who get a horrendously nasty case of SAD in the winter, but can't think of any dev-friendly places closer to the equator I'd rather live, it's as big of a deal as pulling health benefits.

• What is the nature of this "angst" you mention? Is it a) primarily jealousy or b) legit interdepartmental communications issues like difficulty scheduling meetings/general communication.

a) Devs don't need to interact with customers or other businesses. In my experience, the more rigid the company structure, the more mediocre the devs. While much of development is nuts and bolts, it is also a creative problem solving process that requires people be at their sharpest. It's also an unpredictable deadline driven process that results in very, very late hours at times. A side-effect of this is that devs often get the "creative" treatment. In a 30 person company it shouldn't be hard to insist people be adults about employees that need to be at their sharpest when present and are likely to ultimately put a lot more hours in over the course of a year than a 9-5er that's usually packing their things at 4:55 p.m. every day.

b) In a company of 30, you should not be having so many meetings that this becomes a problem. Not counting things like sprint meetings or other bi-monthly planning sessions, tying your devs down for more than 30 minutes every day in meetings is an absurd, grossly incompetent waste of money. Likewise with general communication. 30 people means you walk over to the other guy and talk to him. In flex time scenarios it is reasonable to set a span of time where everybody is in the office at the same time. I can't think of a good reason for that span to be more than 3-4 hours of the work day and why it shouldn't be as close to the middle of the day as possible.

• Why a morning standup?

Why is it that the first idea management scraps from scrum, agile, etc... is always the advice that you not have the standup first thing? In programming it takes a while to ramp back up to the full awareness of all the details and issues you're dealing with on a given problem. When you do standups first-thing, your devs aren't going to have their heads completely screwed on. Standups are critical to communication and improving efficiency, not something you just do first thing to "get out of the way."

• Are your devs failing to get the job done?

If not, why mess with a good thing? It's not their job to communicate with the other concerns at the company. It's yours. In a sane management structure, your accountability is to your immediate manager and the people you manage, not the sour grapes of other departments who have to be there at more typical hour for practical reasons.

Answer 5

Review of the Question: There is lots of missing context and information

As a new technical lead in a new company, what are some additional strategies to employ to change the culture of the development team so that people show up at the time that I've requested?

1. How new of a technical lead?
2. Why are you imposing purely non-technical managerial policies?
3. What are your management credentials?
4. What previous personnel management experience do you have?
5. Have you earned the respect of the team in a technical manner?
6. Have you earned the respect of the team in a managerial manner?

TLDR: My team doesn't show up on time. I've tried to compel them and it isn't working.

Can't provide a solution unless we know specifically why you need to change the culture so drastically. We also don't know what you have tried to compel them with either to be able to tell you why it is ineffective. We can guess, but that is speculation.

Why are you tasked with solving what is arguably a non-technical personel management mandate? Hand it over to a superior who is a manager and let them deal with it. Good Cop vs Bad Cop.

Background Data:

Small company, 30 employees, 5 members of my team. The previous lead is still on staff as a regular developer.

1. Did the previous technical lead step down?
2. Was the previous technical lead demoted?
3. Was the previous technical lead effective?
4. Does the majority of the existing team have a more personal relationship with the previous technical lead?
5. Is the previous technical lead effectively still in charge?

The culture prior to my arrival was one of informality with no set boundaries or core hours. This culture was not challenged by the corporate leaders.

1. Then it must have been working?
2. Was the team successful in delivering useful products when promised?

Most people on the team would show up between 10:30 and 11:00 because of this. Other departments, due to the nature of their work, have set start times of either 8 or 9. This discrepancy and unpredictability causes a lot of angst between my department and other departments.

Specifically how so, there is not enough detail here to even begin to formulate an answer to this question. Any kind of answer would be complete speculation.

As such, I sat the team down and specified a 'no later than' time of 9:30. I explained my reasoning and I explained the benefits of such a scheme and the negatives of the current scheme. It was a long and contentious conversation and 3 of the 5 people on the team were quite displeased.

How about giving us your benefits and negatives without them, we can't judge how reasonable nor how effective your communication may have been. Doesn't sound like you even considered or explored some kind of compromise with your team or the external teams based on their negative feed back. Did you?

Needless to say, people aren't showing up on time (and 9:35 is not on time.)

This doesn't sound like a very positive or effective attitude.

I've scheduled our daily standup meeting at 9:30 as an added motivator. Knowing that it takes a little bit of time to transition start times (with commute, etc...) I initially would wait to begin the meeting until everyone showed up, but now I just start the meeting (and often finish the meeting) with whomever is present. That seems to not be making a difference either and it's making the team less cohesive.

So unilateral actions you are taking are making the team less cohesive. Think about it.

Conversations on an individual and group basis yield the same results as the original conversation (i.e. they don't see the value, think I'm taking away a perk of the job, etc...)

We hear and can extrapolate what they don't accept, do you hear them?

I have the full support and backing of the senior management team and am empowered to employ whatever devices I feel appropriate to get this taken care of.

The Catholic Church had the same power during the Inquisition, look at how that turned out!

My current next step is to send someone home and make them take the day off. Is that too drastic? Are there alternative strategies that I'm overlooking that could help me solve this problem?

Escalation doesn't sound like a viable alternative either. Sending them home without pay is insulting and will hurt the company more than the employee. It will make you look even more dictatorial and tyrannical. Treating them like children will just make them act like children even more.

---

Predicted outcome of your current approach

1. You will lose all respect from the entire team, they will be more and more ineffective, you will be perceived more and more ineffective as productivity grinds to a halt.
2. Your failure with policy change and personell management skills will cause you to be perceived ineffective to your superiors.
3. You will lose respect from people not on your team because of interoffice communication. It will sabotage any future technical leadership opportunities with them as well.
4. You will damage your reputation at the company for sure, up and down the chain.
5. The better employees will vocally quit first.
6. The even better employees will quietly quit after them.
7. The marginally qualified ones may quit or may not depending on the pain you impose.
8. The unqualified ones will hang on like ticks and endure whatever you impose.
9. The company ends up losing, and getting a bad reputation externally by the employees that left.
10. Perception is everything! Never forget that!

Some suggested approaches

1. As their manager you should fight to insulate them from upper management decisions. You should fight for their voice to be heard. You should help them collectively form a response and push back and support them with their response.
2. This is a non-technical decision and purely a corporate management one. Why are you dealing with it and its implementation? Have a superior deal with this, that is their job.
3. Don't act like a dictator or tyrant. Might does not equal right.
4. Take some people skills, soft skills training.
5. Move more slowly. Things like this don't change over night.
6. You need to get the previous technical lead on your side if they have a rapport with the team.
7. Have an alternative compromise, how about the people that don't mind coming in early do it, the other people don't have to?
8. The move of the stand up time is arbitrary, everyone sees this and isn't seen as practical or reasonable but as dictatorial.
9. Have the external teams that you have to deal with be part of the discussion and help you sell the policy changes.
10. Back off, agree with them, be the Good Cop. Get your superior to lay down the law. This is a management problem, not a technical problem. Your are technical lead not a manager right?
11. Have the external team members and your team members just work out times to meet when they need to meet. Predetermined days and times of availability would be a good compromise. The developers don't want to be constantly interrupted by the external team and appear to be there solely to jump to meetings at their demand.

Final Thought:

My Management Style both technical and non-technical is based on Wu Wei Principal of The Tao te Ching.

The Wu Wei principle can be understood by striking at a piece of cork floating in water. The harder you hit it, the more it yields: the more it yields, the harder it bounces back. Without expending energy, the cork can easily wear you out.

The more you do the quicker you are likely to fail. The less you do the more likely the thing you want to happen will get done.

Indirect Transparent Leadership

At first, at best, people hardly notice a leader. Next they adore and acclaim him, then come to fear him, in the end despise him. Thus lost faith breeds lost faith.

Be nondirective, make your few words precious. When the work is done, end gained, everyone will say: We did it by ourselves, naturally.

Get the external department people that have the complaints together with your people in a room and let them hash out an acceptable solution between themselves internally, without you in the room. Be willing to accept whatever the outcome is. Then the solution is theirs, they own it, and you will gain some badly respect from them for letting them work it out. This is the nondirective approach.

Answer 6

Reading through the question, comments and chat it isn't clear to me exactly where the motivation for this 'perk removal' lies between "we need to coordinate between departments" and "other departments are jealous of our perk".

Probably stating the obvious, but if your developers feel that the first reason is just a façade for the second, the reaction you're getting is completely predictable: while you're at it, why not drop their salaries to align with other departments?

If it really is the 'coordination' problem, is it a problem every single day? If not, there must be other possible solutions on a case-by-case basis.

Also, how long have you (and they) been with the company? There maybe 'history' here that you're unaware of.

Update Interesting links for your perusal:

• Computer World: Managing geeks (1, 2, 3)
• Rands: Managing nerds

Answer 7

Regardless of why you're doing it, to your team members it feels like you're taking away a perk. To some of them it may even be one of the major reasons why they're working for your company rather than another one.

Essentially, you're asking them to take a reduction in their total compensation package.

It's possible to convince them to take it, but you'll need good arguments and there almost certainly will be lingering resentment about it. You may or may not lose good people over this.

From your description the main reason appears to be jealousy from other departments. Have you considered giving the other departments the same perk?

In short: Don't do it unless you think it's worth losing some of them over it.

Answer 8

The first thing you need to do is go read "Peopleware"

It is a mistake to try to change this now. I was a manager at a company where we had a pretty flexible work schedule. One of our most productive developers came in at 11am. He reported to me for a while. I was told to get him to change his hours. I fought this request. Hard. I was overruled.

The result:

A less productive, less interested developer who was a huge team contributor. He became far less productive and useful for the team.

All because of some silly notion of "on time".

Focus more on productivity.

Your job as manager is to remove barriers to productivity - not make everyone look, feel and act the same.

Flexible hours are a perk - and an employer who allows flexible hours can attract more quality people.

As a "new technical lead" there is no way you can change culture soon. Especially in the direction you seem to want. Have you done anything to improve your team's roles/jobs?

Work on building trust with them first. So many first time managers/leads make mistakes like this.

Find out what the other groups REALLY need. Not "they have to be here at 9:30". Really find out what the issue is. Then find a solution to that.

Instead of telling your team what to do - explain the issue and then ASK THEM FOR SUGGESTIONS/FEEDBACK.

You make a vague reference to "causes a lot of angst between my department and other departments" - but it is unclear what that angst is - are they upset that devs are treated preferentially? What is the real underlying issue?

I've tried to compel them and it isn't working.

There's a reason for that. And you don't seem to be listening. Reaching for more drastic measure and bigger hammers are not really going to improve the situation. Try the "carrot" approach instead of the "stick" approach.

Again, read "Peopleware".

You are not going to go far with ideas like daily meetings or sending people home or with the notion that they are your minions who need to do as you say, "or else."

Who is telling you they need to be at work at 9:30? Other groups? Your bosses? You? Figure out the REAL issue and address that. When they show up should NOT be the issue.

Answer 9

In my experience, "coordinating with other departments" tends to be the province of those with higher position titles and headed down a project/people management track. Work-a-day devs interested only in code tend to be shielded from this. In more structured shops, they may not do it at all and in smaller shops, they may do it more informally.

Like it or not, you've inherited a flex hours culture, which is a huge perk for most developers. Taking that away from them in one of your first acts as leader not will not only seem tyrannical to them (when you explain to them that 9:30 isn't that early, you're imposing your own schedule on them, arbitrarily in their opinion), but is realistically the subtraction of a substantial perk. You may like working a particular schedule and not consider this to be a meaningful perk, but they probably consider it invaluable. Consider this on par with telling them you're taking away a week of their vacation or cutting their pay by a few percent.

To change that, you can use the carrot or the stick. You're talking about using a stick and, maybe, a bigger stick. If you go that route, I'd plan to hire a few new developers, as I'm guessing that some of your team is going to start going on interviews at other companies. I would personally go the carrot route in order to get buyin for removal of this perk by making it clear that future promotions and advancements will be decided by those who "coordinate with other departments". That is, leaders/important people are in early, working with other teams, taking on responsibilities, etc. "Newbies" get the flex perk, but people serious about advancing get in on time.

If you create that culture, I suspect that some of your devs will start coming in on time of their own accord. Both due to interest in advancement and due to the perception that "the important people get in early."

Answer 10

"Needless to say, people aren't showing up on time (and 9:35 is not on time.)" - Good luck hiring and keeping talented developers.

As a manager, your first goal should not be to motivate employees, it should be to not demotivate them. This is not a step in that direction.

The more you try to force your hand the less productive they will become.

Answer 11

What are your plans to ensure developers stop working and leave on time by 4:30 PM every single day, even if a server is on fire? Are you prepared to pay overtime? Who's going to deploy to production "after business hours"? How about weekend support? Did you even talk about this with your developers? Your developers are going to look at this as a way of you forcing them to work more hours for free; you see, they'll still leave the office at their usual time (possibly 6-7 PM) which means (if they've been there since 9) they will be working 10-11 hours in one day. Good luck when they quit.

It sounds to me flex-time at your company is basically 40-or-more hours a week. What's next? Everyone must take 30 minutes for lunch (and no more) between 12 and 12:30? Because, you know, other departments do that too and they hate when they need to get in touch with a developer after lunch and he/she is out for lunch at 2 PM?

Answer 12

Wow! Thanks for the massive Q&A update! That was really informative.

I don't envy you this one - as a fellow manager, it would be hard for me. And quite honestly, I believe you are going to loose people over it. I think you have a single symptom that comes from the Start Up -> Medium Sized culture shift, and not every developer is going to make this change successfully. So I think you need to be prepared with job descriptions and knowledge of how you open job requests and I think you need to put emphasis on the ability to hire new people and improve documentation...

Sorry that's so grim. But I don't think you have a situation of trust issues, or a case where you can easily explain people into agreement. And there really is no compensation that perfectly balances massive flexibility on the job.

I agree with the posters that you ARE taking away a perk. Flexibility in start time is a big deal for some people, and it speaks to an informal culture that can be a strong preference for some folks. Presumably as the company has grown, workload has become more reliable, job security has improved, respect for the product has increased, and you may have been able to offer some nifty stock plans, pay raises or other improvements. If none of that is true, then you have ask yourself if you have a growing & thriving company or a company plunging into despair.

Trick is, people often can't connect the dots between these new value-adds and the removal of the favorite perk. You can try explaining it, but for some people this is not a good tradeoff, and this is not a case where you can offer the choice. It's a "my way or the highway" since it's having an organizational impact that can't necessarily be felt within the team, but which is experienced and supported at the higher levels of the company.

It sounds like you've done the right things:

• you've laid it out clearly

• you've talked about the reason and need for change

• you've engaged one on one (and continue to do so, I presume) to fix individual cases as they come up

• you've given feedback

I think you're down to the "does he really mean it?" point where it's mostly proving to people that you are serious, and that this really needs to change. It'd be my personal opinion that being 5 minutes late in an office in my region is not a big deal and that meetings that have a short span (like stand ups in an agile sprint) shouldn't be so smack up against the start of the work day that a missed bus connection or bad traffic is going to be a regular problem. But this is somewhat regional - different locales have wide variations in the traffic situation. So that's as much knowing your region and knowing from individual complaints what's reasonable.

The rest is just coming up with a mechanism that is debilitating enough to prove that you are serious. A day of docked pay is one option and it is within your legal rights - although any mechanism I'd come up with I'd run through the lawyers. So is a formal warning system that leads to discplinary action. I'd assume that your HR department might have suggestions...

A lot depends on what the work can tolerate - when you send someone home, you also loose out on that day's work, which impacts your cost & schedule. When you have a warning system that leads to disciplinary action - including termination - you save the rest of the day's work, but risk having to fire the employee.

I think the thing is, when you deal with punishments, you have to be prepared with a punishment that is damaging enough to be taken seriously and to drive home the point that "you are not doing your job if you are not doing this".

Answer 13

It seems that there's a disconnect here between how your developers see the issue, and how the other departments (or your superiors, or whoever it is that's actually demanding this change) see the issue. I would suggest trying to bridge that gap, in multiple stages if necessary.

First, do the developers agree that there are good reasons for this change? If they disagree, do they have any good counter-arguments, or alternative suggestions? If they do, you should bring those to the management and see if they'll relax the timing requirement - or if they can explain why the alternatives won't work and the counter-arguments don't solve the issue, so that you can go back to your developers and give them a more complete explanation. Continue the back-and-forth as long as necessary/productive.

If you get to the point where the developers agree that there are good reasons but just aren't willing to adapt, or they don't think the reasons are good and resent the whole idea, communicate that to management. Explain that you could force the developers to do what is wanted, but it will cause resentment, lower motivation, quite possibly lower productivity or even employees leaving. Make sure the management understands this and still agrees that it's important to enforce the start time (and again, communicate this to your developers), otherwise you may end up responsible for a change that lost the company more than it gained.

_{(A personal note: I've been in the position of being told to come in at a set hour for, as far as the employees were concerned, no good reason, and it's really extremely unmotivating. It's really important to make sure people understand the reasons and don't feel like you're just changing the policy on a whim or because you don't trust them.)}

Answer 14

There are still multiple avenues available to you for handling this issue one of which would be to change the role that the department plays such as for example: If you are working with software developers you could change the role for a certain or people during the week to have them do support for the other departments, which requires 1 or more to come in at 9 or earlier and if that doesn't work you could always invoke an insubordination clause which normally is present in any employment handbook in the US. Personally I've always been against using this clause, which gives a manager an avenue to reprimand and even fire someone for cause but in your case this may be appropriate. So review the employee handbook and discuss it with your superior if you have any that you will be doing this.

The basic idea is as follows:

1. You set the rule that at least 1-2 or all people should be at work by hour X.
2. If your team members don't have a valid excuse not to show up or persist in this practice you as manager should reprimand them and possibly fire them.

As a manager doing what I described would be the last resort but based on what you are describing you may have reached that point. There are many articles on could constitute employee insubordination that you can find online and these are just a few examples:

• BlogSpot
• Duhaime

Of course the unfortunate consequence may be high rate of turn over in your group which would poorly reflect on you as a manager but it will enforce the discipline.

Now having said all of that I do have one question: Do you really need your team to be in earlier then when they come in?

Answer 15

I used to work at a non-profit that had this problem. Meetings always started late, 10 minutes late became a "standard".

They we got a new project manager for a big key project (and one on a fixed timeline). She called the first meeting. People strolled in as usual, minutes late and casually chatting. She sat in her chair and said nothing - nothing at all - for several minutes. Eventually the chatting "died down" until there was silence. We were all waiting for hear to speak. She allowed the silence to continue for a little longer. They she looked around and said "I need to make it clear. Meetings start on time. If you're going to be 5 minutes late, don't bother coming, just see me afterwards. OK, now for the project we're doing this week [whatever]...". This made a BIG impression and people made a real effort to be on time for her meetings.

Note: Added additional answer below.

Account for work done remotely.

Often the highest producers do a large part of their work remotely anyway, so they're sometimes putting in as much time remotely as in the office. This is an important point to both consider and communicate with the other departments. That communication should be subtle - don't call a meeting, just start looking for ways to show "yeah, joe was up late last night working on x" and "yeah, Mary fixed that on Sunday, she was up 'till like midnight'.

Talk openly about the commute. If someone comes in at 10.30, their commute may be 15 mins. If they needs to be in at 9 or 9.30 their commute could be an hour. Plus it would be the same going home if they worked 8 or 9 hours. Many people feel this is a major waste of their life. They'd rather work remotely for a bit and then come in after that. Look to integerate this fact with your needs when setting times and make sure other departments know about that too, again by mentioning it frequently.

Make sure you use technology to help. For instance I work virtually - 100% of the time. So having Skype on, showing my status as online, a video-cam, etc. can help too.

Answer 16

The short answer is that you should NOT do this. Your technical team members are (or at least, should be) smart enough to know that there is no tangible benefit to having everyone present at the office by some arbitrary time; the only important metric is whether or not their work gets done.

If your team is not getting their work done, then that is a separate issue. But if they are getting things done, then why are you harassing them just because other departments have been harassing you?

Part of your role as a leader is to insulate your team from trivial distractions and criticisms brought about by external sources. If your reaction to other people complaining about your team members is to pass the complaints on to your team members and/or dictate changes based solely upon those complaints, then you are failing at your job. I'd suggest that, assuming that your team is in fact getting its job(s) done (which it sounds like they are, since you make no complaints about their productivity), a better way to respond to such criticism is to tell the complainer "yes, well my guys work hard and consistently deliver solid results, and that's the only thing that matters; so why don't you stop worrying about how my team handles their tasks and get back to your own?".

And of course, if you do go through with a mandatory "you must be in the office by time X" policy, it's only fair to complement it with a "you must leave the office by time Y" policy, and a "you must not work from home outside of normal business hours" policy. That's only fair as a way to protect your employee's work/life balance, as I bet many of the team members you have who do not show up until 11:00 are probably either staying back late or putting in extra time at home.

Answer 17

Having been on similar situations, though admittedly in less time than the OP, I only have this to say about the state of his situation:

The most practical and simplest solution...

...would be to try start the meetings at 11 o' clock instead. Don't worry, you're not "giving in". Instead you're redirecting the flow much like the principles behind Aikido. The idea is to instead focus on enabling your team to get important things done as it is the paramount point because there really is one serious problem that needs to be adressed:

The team really has NO idea what is up with the other departments and what they REALLY need to do

Having your team to show up at 9:30 which I can admit is not early is however not a solution to this problem. You have tried and failed so stop insisting to do so. Stop banging your head on a brick wall. My only tip here is to always value communication over arbitrarily set meetings.

Since the other departments start at 8 you can use this late team meeting to your own advantage. Between 8 and 11 you have 3 hours to help your team with project management activities such as (in no particular order or priority):

• Go to meetings and gather goals and requirements from the other departments
• Figure out what was finished since yesterday
• Manage expectations and commitments with the other departments on what needs to and can be done during the work day
• Deliver good news and bad news to the other departments
• Update any plans relevant to the team if there are any
• Figure out what code and software architecture issues needs to have attention today
• Saying "NO" to requests that do not provide any business value
• Accept criticism from the other apartments and apologize with assurance that issues will be fixed
• etc. (there is always something that needs to be addressed)

And finally before the meeting summarize a brief for the team on what is happening, in order to give them some situational awareness. When the meeting starts at 11 and everyone is fresh to get to work you have information and a meeting protocol prepared for them. You can have the brief and minutes from the meeting written like a newsletter and send it as an email sometime after the meeting as a gentle reminder.

During the meeting with the team you need two things from them:

• Ask for estimations for tasks that need to be done, especially those that are in high priority. It doesn't have to be precise, as in minutes. With this you can decide commitments and deadlines much more clearly with the other departments. If they can't give any estimation for a task, ask them to figure it out during the day or the next.
• Ask for impediments or if they need help with anything, write that down and see to it if those issues are fixable and that they get fixed.

After a while you can probably gradually move have the meetings earlier. But initially going against the grain is not the way to go and only lead to even more infectious culture (in which the only way to repair is to replace the whole team). If they are, as you say, "primadonnas" then your real job is to refurbish them into awesome primadonnas that deliver with high quality. It is clear that your team had and wants autonomy so start exploiting that culture to the advantage of your company's goals.

When you've managed to make a dependable team, through communication rather than coercion, you can leave 3 hours earlier than everyone else in the team knowing they're doing their job (but still be on call if the crap hits the fan). Now that's trust that you can count on.

Answer 18

I'm reading comments and answers and I have to confess, I'm a bit flabbergasted. Since when is having people show up on time "loss of a perk"? Since when is flex-time not having to care about the impact of your actions on the rest of the team and company?

From what I read in the question and comments, the behavior of his team-members is provably detrimental and costly to the company. And after trying to reason and compromise, the situation has not improved (and btw, 9.30 is not early or in any way unreasonable).

Explain to your team that you have no problem with flex-time, but that it implies a certain amount of personal responsibility to make sure your flexing is not impacting the work of others (on your team or other teams). As your team is clearly failing on the responsibility part, I would say that effective immediately and until further notice, all flex-time has to be approved by you beforehand. Failure to show up on time in the morning without approval or a reasonable excuse (no, alarm-clock did not go off is not acceptable) will result in disciplinary action like docking pay or vacation time.

Be very clear why this is happening and what has forced you to take these measures. Point out that this is not something you want to do, but something that you have been forced to do. Also be clear that these restrictive policies can be lifted once the situation improves.

Answer 19

The others raise a lot of good points about how to handle the situation; however, at the end of the day, if the schedule of your group is disrupting others in the company then you must correct the problem and ensure that things run smoothly. With this in mind, you need to find out when other groups need reliable access to the developers and if there is any room for flexibility in that schedule. If other groups need access to developers when they are at the office on an unpredictable basis then a core segment of developers need to make sure that need is accommodated. If this means that some developers have to be at the office at fixed periods of time, then it is what it is.

With regards to moving the developers to some sort of a fixed availability schedule, your best bet is to ensure that any "hard hours" are softened as much as possible. For example, if the "core hours" are from 11:00 to 15:00 then you can also make sure that the core hours on Friday are not present and Friday is a true flex time day. As Tuesday, Wednesday, and Thursday are traditionally considered the most productive days of the week you might be able to have the core hours apply to those days and allow Monday and Friday to be full flex days as well.

In terms of ensure that the hours are adhered to, if the direction comes down from the top and is approved by upper management then ultimately the developers must adhere to it as part of their employment. You should do what you can to ensure that it is phased in and if some developers have flex-time written into their employment agreement it should be addressed (eg. by changing their compensation and benefits, grandfathering them in, etc.); however, at some point you are going to have to ensure that the policy needs to be adhered to which may also require official disciplining of employees. Likewise, if some choose to leave it may be worth trying to see if they are willing to stay with compensation and benefits changes; however you may also have to accept losing some of the developers.

Ultimately, if your job requires that you enforce a cultural change to the group to meet the needs of the business then you options are going to be limited to an extent. You can and should do everything to soften the change and elicit any compromises with other groups as you can, but eventually you will need to enforce the change and accept any personnel change that may come with it.

Answer 20

Put it on your staff to show they can get things done and still not show up "on time". Having quality people working in an environement where they can be the most productive will make any supervisor's job much easier reguardless of how much damage control you have to do with the rest of the staff.

A compromise could be made where there is a rotation so someone from your team is available without requiring everyone to be there.

The eureka moments don't all happen 9-5.

EDIT: This is based on you being required to run your team this way by upper-management. You're going to have to give people lesser roles on projects who do not show up on time. If their attendance gets worse, take it out of their bonus. Eventually, they'll have to be let go. Seems like your superiors will support you. Unfortunately, they'll discover that they've put this artificial benefit of punctuality ahead of having quality people.

Answer 21

I think the issue here is far more than the loss of a perk. It is that the team does not respect your authority as a lead.A possible cause of this is the ex-team lead who still there as a developer. A person who has been demoted for bad performance often has a reason to make sure the next guy fails.

Even when a lead makes an unpopular decision, the employee is obligated to follow it. Employees who can't do that aren't worth keeping.

It is not the lead's job to be popular, it is the lead's job to get the job done. If the current way of doing business is not working, and it is not since others are complaining, then a change must be made. From the description above, flex time was never a company benefit, the team chose to ignore company policy.

I would write up these people first and send them home without pay next (after consulting with HR) and if that didn't work, I would fire them. They are not professionals; they are spoiled children. This arrogant attitude will infect everything they do and they will not get better without there being a punitive action becasue they don't think the company should have authority over what they do. They need a wake up call not more coddling. I have never seen anyone with this attitude be a good developer or a team player and unless the person has a skill no one else in the market has, he is highly replaceable.

Answer 22

I was a new lead once and I have run into same problem like you.I tried to enforce the punctuality to my team and I failed horribly. Even my higher management also doesn't helped much. Based I had a good learning exposure.

First gain team trust, respect and admiration: Once you earned these from your team then the chances they value your opinion is more. Obviously they try to impress you and then they will obey what ever the solutions that you suggest for the goodness of the team.

Fix the issues in team and issues for the team not the persons in the team: As a lead we are getting payed to fix the issues those are related to team which impacts the project and not the issues with persons. If some one plays game WoW whole night and over slept that is his problem and not team problem. Don't interfere if he is still productive and meeting expectations. You can interfere if you receaved any genuine complaints and issues because of his acts/habits/attitude etc.

If Designer Y comes 8 AM and he needs Developer X assistance or involvement to finish his job. It is Designer Y's responsibility to talk with Developer X well before about this and schedule a meeting. If I am in Designer's position I have schedule one to one meeting with Developer and figure out various dependences and come up with action plan to address it. You have to involve when you hear any escalation from Designer Y. If designer Y is failed to escalate on time, it is designer Y problem. But as a lead you proactively check with Design team periodically about any issues. If design team raise concerns about punctuality issues of your team, you say that we are running on flexible time. If they need any thing from your team ask design team inform to developers well before and schedule accordingly. If developer failed to respect the schedule or not showing up as per schedule then you can ask the developer and take action on developer.

Finally if it is really causing consistent problem and source of complaints from other department, have a team meeting and discuss about how to resolve this issue. Open for suggestions. Take all ideas and analyze your team ideas for merits and demerits for the project. Finally which best fits project and team interests implement that one strictly. That solution is might not best for team members interest, But make sure it comes from team and not from you. The successful leaders will make the team member to tell what he wants to tell. This is the best trick that leaders play. Use this trick. If you find team already gave the idea what you want like implementing punctuality, you gave another idea which can fail project merits and team merits. Obviously while discussing that idea failed to address team and project interests. And the idea which addresses the project and team interests will win. In that case you show case the attribute of willing to make the ides which team gives and strict on your ideas.

Answer 23

I would start by scheduling meetings at say 9:30 -10:30 providing Danish Pastries and doughnuts. If people miss meetings then they get the boring but vital tasks assigned to them - say go through the teams quality docs and reconcile them against your ISO9000 TQM system.

I would also make managing actions assigned to them and reporting on them in a timely manner part of your team members job description and have it feed into their PDP