Take the 2-minute tour ×
The Workplace Stack Exchange is a question and answer site for members of the workforce navigating the professional setting. It's 100% free, no registration required.

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.

share|improve this question
76  
One important thing is missing from this question: WHY are you making this change? Is work not getting done in a timely manner? Is there an actual problem that needs solving (and is this the right way to solve it? Might be a subject for another question...) As Andrew pointed out in his answer, dictating an arbitrary "not-after" start time to knowledge employees who already have a flex-time culture is going to be unpopular, and it's hard to suggest motivators/methodology without more context... –  voretaq7 Apr 12 '12 at 19:02
68  
Are you willing to enforce the flip side of your 'school bell' rule? Everyone stops what they are doing and leaves at a time certain no matter how much work might still be undone? –  Jim In Texas Apr 12 '12 at 21:24
58  
Needless to say, people aren't showing up on time (and 9:35 is not on time.) this sounds dictatorial, micro-managing and tyrannical. Sounds like you need minions; look for those personality types when the current crew quits. –  Jarrod Roberson May 7 '12 at 20:51
32  
The moment you say: (and 9:35 is not on time.) immediately give me the impression you are a harsh boss and I would less likely to listen to what you say. Programmers pretty much everywhere have always have work hour flexibility, and most of the time people falls to a routine, it's unlikely they are unpredictable when they gonna come. People do this mostly because of what work best for them and in turn that makes them more productive. –  tsOverflow May 12 '12 at 4:44
40  
Still sounds like the problem is with you not the rest of the team. You have a dictatorial tone here, I can only imagine how you come across to the people that you are supposed to be leading. The feeling I get is this is either your first or second time in this position and you think they should just do like you say because you are in charge. There is a culture in place for good or bad; you need to adapt to it and change it by example from the inside. You came here asking for help, but don't want to listen to anyones opinions. This should really be How can I bend my employees to my will? –  Jarrod Roberson May 12 '12 at 23:42

17 Answers 17

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.

share|improve this answer
6  
+1 - I think this is the most concise way to phrase the problem and the solutions. Whatever rules you set need to facilitate getting things done, and that's how this should be approached with the employees. –  voretaq7 Apr 12 '12 at 19:46
30  
@JacobG You know, the second developer does have a point - being able to come in between 10:30 and 11:00 am is a perk, even if it's one you don't approve of them using (like, e.g, smoke breaks). You shouldn't remove it without offering some form of compensation. –  Tacroy Apr 18 '12 at 16:37
9  
+1 absolutely agree. I would add that perhaps the problem can be mitigated by considering having "coverage" during core hours rather than having everyone on-site at core hours. Can some devs volunteer to show-up earlier while others stay later? –  Angelo Apr 23 '12 at 17:40
8  
when people have bad habits, rewarding / compensating them for giving them up is not great. I'd rather reward and compensate for results. –  Michael Durrant May 8 '12 at 1:41
5  
As a team lead or line manager working with smart, creative people, the most important skill is listening. As long as the team is productive and effective, don't get in their way. In this case the pressure is from outside of the team - I see my role as protecting the team from this kind of "organisational rain" and so tend to end up fighting for them with management, not the other way round. If the team is efficient and productive, then don't mess with it. If the timekeeping breaks down team cohesion, then ensure it is raised in your retrospectives as an issue for the team to resolve. –  GuyM Nov 23 '12 at 22:04

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.

share|improve this answer
5  
"Let them come up with a plan" was my first reaction too. However, judging from comments and chat, that doesn't seem likely to work in this particular case... –  Benjol Apr 13 '12 at 6:45
16  
@Benjol - The tone of the question makes me think there is more to this than meets the eye. It feels too Theory X style management, which isn't effective when managing developers. We're only hearing one side of the story, and the truth is always somewhere in the middle. –  jmort253 Apr 13 '12 at 6:50
4  
The most important point is this: Forcing smart people never works. You can't treat your highly intelligent team members like children and expect them to not complain, fight back, and resent you for it (case in point; I'm not directly affected by any of this but I still find it hard not to take personal offense at how the OP is trying to manage his team). Technical employees are generally about as smart as their managers (if not more so), so the only effective way to approach them is as peers, not as mindless underlings who should do what you say because you said it. –  aroth Jul 12 '12 at 23:50

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.

share|improve this answer
13  
@JacobG I can't say if you're being unreasonable without more info, however the key to flex time is that the work must be getting done. If what you're saying is the work is not getting done, stripping flex-time from the unproductive employees (or docking pay/vacation time) may be the way to go. In your example. Dev X and Designer Y should be coordinating so neither is sitting twiddling their thumbs waiting on the other. If that's not happening that's a process problem as much as a schedule problem... –  voretaq7 Apr 12 '12 at 19:04
36  
you will lose your good ones to other employment - that's the heart of the whole issue, @Jacob. If work isn't getting done, then you have deeper issues; your devs and designers need to coordinate better. If work is getting done, then don't waste developers' time with nonsense like setting a specific start time. –  Adam Rackis Apr 12 '12 at 19:26
22  
+1 for losing to other employers. If I were going from an environment where I was trusted to keep my own schedule and get my work done to a clock-punching environment where I got tardiness demerits, I'd be dusting off my resume. –  Erik Dietrich Apr 23 '12 at 15:17
12  
@JacobG If I were coming from a flex hours environment and now part of "satisfactory" is "being on time", then absolutely I would (and, I think, so will your team). Flex hours isn't a matter of gamers to play video games all night - it's about a culture of trust. If it's my team, I trust them to know their own personalities and preferred work hours well enough to get things done. Rescinding the flex hours means rescinding that trust and sending the message that they need to be (micro) managed because they're lazy and incompetent. Even if it's true, they won't like it. –  Erik Dietrich Apr 24 '12 at 15:18
11  
@Ramhound The problem is that the previous culture was one in which 9:35 was NOT late, and the OP want to shift to a culture that it is, presumably for people with talents that are not easily replaceable and who have some level of freedom about where they can work. He can shout "YOU ARE LATE," I suppose, but that may result in some people leaving and lower morale, which it sounds like he is trying to avoid. –  JohnMcG Jul 12 '12 at 17:33

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.

share|improve this answer
9  
I gave an answer to the question. And then a really long followup/addendum. –  Erik Reppen May 11 '12 at 6:03

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.

share|improve this answer
10  
+1, These are all really great approaches. Personally, I like the approach of empowering the team solve the problem. It's amazing what adults are capable of when they're treated like ... well ... adults. Martha needs to meet with John, so they plan and coordinate together, without the big mean nasty boss to come in and play dictator. –  jmort253 Jul 12 '12 at 7:41
9  
@JacobG "was put in place via a 2+ hour discussion" is a oxymoron. "was put in place" implies a unilateral decision dictated by someone and applied. Most places I have worked in the past 22+ years realized that there should be a separation of Technical leadership and management. This is a very well established organizational structure in most large ( I mean multi-billion $$$ a year ) companies I have worked for as technical leadership. Conflating the two responsibilities is a recipe for strife. Having 2X 2+ hour discussions should tell you the policy is bad and the approach is worse. –  Jarrod Roberson Jul 12 '12 at 18:19
6  
@JacobG you keep saying you discussed it with them, you didn't you told them how it was going to be now and apparently there was an argument for 2+ hours. That isn't a discussion about a policy shift. A real discussion would have been we have the following complaints from other departments, one idea from those teams is an earlier start time, what other ideas do you guys have that we can float back to the other teams to to resolve the actual issues they have?. Since it doesn't seem that having everyone 100% of the team there early is actually the problem. –  Jarrod Roberson Jul 13 '12 at 14:55
5  
@JacobG a discussion implies bi-lateral communication, by your own admission even here, this was a unilateral communication of how things are going to be now. "I've scheduled our daily standup meeting at 9:30 as an added motivator." is an arbitrary stick trying to force compliant behavior. Everyone reading this perceives that, your "team" perceived that for sure! It is a rule that was put in place that they see as a punishment for actions not yet taken and are rebelling. If you won't accept this perception, nothing you do will be effective. You are clear, you aren't listening to them. –  Jarrod Roberson Jul 14 '12 at 18:52
6  
Reading this discussion, it occurs to me that the real problem here is that higher-ups are making determinations on details that shouldn't concern them. Every tier should concern itself with inadequate results from the tier below it. The how should be in your court. That the devs are pretty much blowing everyone off at this point suggests to me that they are both fed up and not at all worried about finding new jobs if it comes to that. If they want to play it like that, they'd best gauge the difficulty of replacing most of a dev team. –  Erik Reppen Jul 18 '12 at 0:25

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.

share|improve this answer

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.

share|improve this answer
5  
@Chad - The answer is implicit in the second paragraph: Pay them more –  CurtainDog Jul 12 '12 at 8:08
2  
@CurtainDog - Unless the pay raise is contingent upon showing up on time then I doubt this will be a lasting solution. If it is contingent then we kind of agree. –  ReallyTiredOfThisGame Jul 12 '12 at 20:20
2  
Would it be possible to edit this post and expand on how to give the other team the same perk? While this post does offer an alternative, it doesn't really go into depth or address the fact that some of the employees may be shift workers who must have a schedule. –  jmort253 Feb 12 at 2:43

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

share|improve this answer

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

share|improve this answer

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.

share|improve this answer
4  
Except the author claims work isn't getting done. –  Ramhound Jul 12 '12 at 12:00
5  
@Ramhound - No he doesn't, at least not in the original post. In the laundry-list of edits he mentions that performance has been on the decline recently. But as the team has always had flexible working hours in the past, there's still nothing to show that the decline of performance is correlated to working hours, or that setting a firm start time will cause any improvement. Judging from the original post is seems like the author is most concerned about the negative feedback that he gets from other departments. –  aroth Jul 12 '12 at 23:26
1  
Sounds like "the beatings will continue until morale improves". –  gnasher729 Aug 1 at 22:59

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

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer
1  
I think this is more good solid advice, and a good alternative approach that would lead to success. The role of a manager/team leader is to insulate the team from noise and confusion and remove obstacles that reduce their efficiency. This answer proposes an approach to do all those things! –  Jarrod Roberson Jul 17 '12 at 14:49

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:

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?

share|improve this answer
2  
In response to your question - Yes. We have multiple departments with whom we work regularly. These departments are in between 8-9 and leave between 4:30-5:30. A late start time and lunch means, at a minimum - 1) No meetings before 1pm and 2) Wasting half of a day or more if someone is waiting on something from our department. Incredibly inefficient. –  Jacob G Apr 12 '12 at 18:21
9  
@JacobG the classic consequence is "You stay late to finish the work, or we dock vacation time". With respect to "everyone" finding 9:30 a reasonable start time: I don't. Then again, I work until 8-9 at night, sometimes later, and often after I've gone home. Those are my most productive hours, and I wouldn't put them in if I were expected to walk in the door at 0930 sharp "or else" - I'd become a 9-to-5er. Every team is unique, and I hope you're considering that in your evaluation... –  voretaq7 Apr 12 '12 at 19:07
7  
@Jacob - what sort of dev team is this? Are you guys just another company maintaining the internal X app, or are these high-quality developers writing solid code that's the backbone of your company? If the latter, some of them expecting to be able to work late from home and come in late seems unsurprising. I would suggest you try to accommodate that. Quality developers are incredibly hard to find. And they always have other options if the current job isn't working out. –  Adam Rackis Apr 12 '12 at 19:40
2  
@JacobG Why is it 'wasting half a day'? Are these other teams arriving at 8am in the morning and then suddenly realising they need something from a developer? –  robertc Jul 12 '12 at 12:52
6  
@JacobG None of the examples you've listed are development tasks. Even if you're having your developers do client support (as you are implying), why do all your developers need to be in the office at a certain time to do support? Why have you promised specific turnaround times to clients and other departments on support issues when you don't have dedicated support staff? –  robertc Jul 12 '12 at 15:03

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 is 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 obliged 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.

share|improve this answer
6  
A developer who blindly follows leadership decisions is a bad developer, plain and simple. You don't try to manage highly skilled technical workers the same way you'd manage a factory full of unskilled laborers and expect to get good results. –  aroth Jul 12 '12 at 6:09
7  
@HLGEM - Yes, those leaders pay me to use my skills to help the company succeed. They do not pay me to be at their beck and call or to do things "because I'm the boss and I say so". Any "leader" who expected me to be at their beck and call simply because they pay my salary wouldn't need to fire me. I'd resign on the spot and go find a more reasonable employer. I reiterate; you cannot treat skilled, intelligent technical staff members like children and expect to get any sort of positive results. It just does not work that way. –  aroth Jul 12 '12 at 23:32
4  
@aroth - You seem to have a chip on your shoulder. You saying you would simply quit is easy to say, harder to actually do, if all that is asked of you is to show up ON TIME. –  Ramhound Jul 16 '12 at 15:38
3  
@Ramhound - That's a fair point. I cannot stand corporate culture. And I have a difficult time tolerating people who advocate such cultures. However I do my best to keep the discussion civil and on-topic. And the issue isn't so much what is being asked, it's how/why it's being asked in the first place. I'm not going to so much as give someone the time of day if they "ask" me to do it with an attitude of "you will do this, because I'm telling you to do it". That's not an acceptable attitude or reason in my book. –  aroth Jul 16 '12 at 22:51
5  
All this tough talk about not being bossed around comes to a hault when you have to explain why you are currently unemployed and why you left your last job. "Because they made me show up on time" will get you sent home. I call a meeting at 9:30 I expect asses in seats because dollars shouldn't wait on dimes. –  JeffO Oct 1 '12 at 20:35

protected by Rarity Jul 12 '12 at 11:48

Thank you for your interest in this question. Because it has attracted low-quality answers, posting an answer now requires 10 reputation on this site.

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.