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.

Final Update

From the original crew of 5, 2 have been replaced. The first was the previous team lead. We could not see eye-to-eye on how to run development projects and he could not accept changes to what he had previously laid down, so we mutually agreed to part ways. The second lost interest in the work, made a couple of big mistakes and we also mutually agreed to part ways.

The team, as a whole, now shows up early enough to ensure plenty of coverage for the rest of the company. What ultimately worked was mandate and peer pressure. In addition, other changes that have been instituted have resulted in nearly all of the inter-departmental angst to be resolved. Everyone still gets to work on awesome projects, mostly of their choosing, at their own pace at an exciting company and they are all quite content despite the job market being ridiculous in the area.

I have been promoted to an executive position and the new 'problem team' has been moved under me (in addition to still retaining control of the dev team and still developing.) I'm now working to help them perform better and be better teammates to their colleagues. I don't have the punctuality issue with this new team... Their issues are accuracy and communication.

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

Creating a culture of punctuality may take time and may be something you have to compromise on somewhat. Since you're dealing with intelligent knowledge workers, you'll be more successful if you can get them to buy into the plan. Instead of focusing on the time, focus on the problem created by the scheduling issues.

Present the problem as a challenge to the team and see what they come up with. The answer may be set schedules or it may be something different that solves the problem. It may be Monday, Wednesday, Friday are the 9am-sharp days while Tuesday and Thursday are the flex days. While the plan may not be perfect nor will it be exactly what you envisioned, finding a middle ground somewhere that will make both the development team happy, as well as solve the actual problem will prevent your staff from becoming bitter and seeing you as the enemy.

Keep in mind that 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. This goes back to putting the problem in their hands, at least at first. If they do nothing, then you'll want to step in with your own solution.

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, and other knowledge workers, 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.

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.

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 needed respect from them for letting them work it out. This is the nondirective approach.

Answer 6

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 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

To change your culture you need to realize why you are experiencing resistance and then manage the cause of the resistance.

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 9

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 10

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 lose 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. 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 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 11

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 12

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

Then 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 13

Having been in 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 to 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 three 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 14

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 15

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 16

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 and likely kill morale in the process.

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 17

Basically, you have to decide what's more important, getting the job done properly or sitting at your desk for 8 hours at prescribed times?