Looks like a convincing start of the page. Approximately 90 questions on the first day - not too bad.

@BenBrocka Congratulations. I see you've managed to get the mortaboard. :-)

@Markus 3 days now, actually. Still a good start, though IMO there's some overly broad questions and too many basic answers yet

@Markus yep...I don't even think I got that my first day on Cog Sci...

@JacobG I have some further thoughts about workplace.stackexchange.com/q/450/50, but I think the comments will get a little chatty if we just go back and forth.

Isn't what what chat is for? :)

@normalocity Yes, of course. :) I'm just trying to get a message on his radar, though I have no idea whether I was successful.

What do you think about the site in general so far?

I'm just kind of keeping this window open while doing real work. Curious to see people pop in and out of here.

I see that the (very early) indicators are mostly good: area51.stackexchange.com/proposals/30887/the-workplace

@Andrew they have to have been in chat recently to get your ping, otherwise leave a comment inviting them to chat

@BenBrocka Thanks -- I wasn't sure how that worked.

If you're going to leave a comment you can just type [chat] to drop him a link to chat as well

Hey Andrew

so is this beta chat lively? :)

Hm, depends on your definition of lively. Take a quick scan through the timestamps along the right edge.

I decided I'd lurk today to see who comes along.

@JacobG it sounds like we're missing a big piece of that picture - is there actually a productivity problem?

(and if there is throw up questions about that too - my impression is that there's a coordination issue between dev and design where devs aren't leaving work in the hopper for the designers to look at in the AM)

Yeah, on a couple of levels. The first is that work wasn't getting done in a timely manner just in general. The second is that the other teams are being dragged down by the lack of availability of the dev team.

My strategy coming on was to fix the perception of the team in their interaction with other teams in the company and use that as a catalyst to attack the other issues

@JacobG Cool. I think some of the other answerers/commenters are making the point, though. The real problem appears to be that work isn't getting done.

@JacobG yeah - it sounds like what you need is closer coordination, making sure that the overlap time is used effectively and that when the devs leave at night they've left stuff for the other teams to do in the morning so when they come back at 10-11 they can get feedback & make changes.

the big problem you face is the existing flex-time culture combined with what sounds like bad work habits

The Design and Dev projects currently come from different hoppers (I'm working on that as well) ... Many times, the designers will need the assistance of the dev team and no one is around to help them. So, they end up twiddling their thumbs for 3 hours, get criticized from the owner of their project funnel and then point the finger our direction...

Yeah, I'm trying to shift the existing culture and it just isn't working...

yeah THAT'S a problem -- have you talked to the devs about the external perception?

Oh yeah... that was my big justification for making the change

shifting the existing culture will be hard because flex-time one given can't really be taken back. The better solution (IMHO) is to fix the coupling between the two departments, which isn't easy either but it's not as hard as stripping flex time

We have employees that are here at 8 am every morning, for example. They see the devs roll in at 10:30, go to lunch at 11:15, come back at 12:30 and then finally get to work.

Sure the devs were staying until 8 or 9, but we're 30 employees in a small open office and the dev team has only been around for about 3 years

So it's an internal PR nightmare

I came up with 9:30 by taking the latest start time of every other employee and adding 30 minutes...

that's nice - but these aren't your other employees :-)

It was an attempt to justify that it wasn't an unreasonable request ;)

I don't think it's unreasonable, but you've got a bunch of spoiled developers and you're effecting a huge change in corporate culture - it's easier if they feel they had some say in it

I presume that the devs who come in later are also staying later? If so, they may be the type that work better at least part of the time without any distractions.

OK, they are. Sorry, had to answer a work question in the middle of typing that.

Are the designers capable of working independently or are they bugging the devs constantly? That could also be contributing to the attitude.

These are honestly the best designers I've ever worked with. I don't feel that they bug the devs an inordinate amount.

Could some of their questions/needs be communicated through email instead of in person? In many places, it's customary to respond to email fairly quickly (same hour, maybe, or within a few hours for important, internal needs), but it can give devs more control on the fragmentation in their day if they can have a little more control over when they stop and handle requests, in an asynchronous way.

I agree with a lot of what's being said about not letting your dev's be spoiled though. I'm a dev, but you have to deliver, and you can't bend the rest of everyone else's day to your preferred working methods. Just throwing out some additional ideas here.

This is exactly the type of feedback and information I'm looking for... I asked when I first came on board about the reasoning for the late hours. I was told by the previous lead (still on staff as a developer) that he "wanted to create the most awesome fun development environment possible."

I think it's easy (regardless of what the role is) for any group in any organization to want to have some control over their day, and it's easy to let one group control others if they're allowed to. I'm a permissive person, but I would definitely appeal to the greater need, that the coupling between the groups is what's important, as has been said.

Well, as for "The most awesome, fun, development environment possible," I commend any manager that really cares about the people that work for them, and the work environment they work in. That's always greatly appreciated. However, your place isn't 100% developers, so (like in any relationship) there have to be compromises.

If the devs (or any group, really) are acting like a bunch of, "We are the most important people here, and we will dictate other people's work schedule," then, well, that's not thinking about what's important for the entire organization to function well. It's not really fair.

Collaboration is important, and while no one wants to feel subservient to the whims of any other group, there needs to be cooperation. Isn't that just the mature way to act (totally unsubstantiated opinion)?

The first response I received from one of the devs when I first brought up our PR problem was "Well, if Customer Service has a problem with what I'm doing, then they should go back to school and get a degree." I've continued to try to appeal to reason, professionalism, teamwork, corporate trajectory etc... and been unsuccessful. I've never had to reprimand someone for something so trivial, but I feel like I made this hill and that if I don't defend it, I'll never be able to make another one...

I agree. Defend it.

Besides, that's a completely ridiculous response from the dev.

Tell them they're pretending they're acting like a pre-Copernican Earth in a helio-centric universe.

LOL

You'll get points for the science reference.

*Tell them they're acting like a...

bookkeeping question - Should I edit my question to include some more of these details?

I'm not sure "defending the hill" is a constructive way to look at the issue, though. I don't exactly think you've made a mistake here, so the adage of "admitting your mistakes shows strength" doesn't exactly apply, but I think showing that you are willing to work with your devs does show more strength than what will be viewed as arbitrarily defending what appears to them to be an arbitrary policy.

The truthful, blunt response would be something along the lines of...

@normalocity I agree that was a pretty bad response.

There are absolutely times to work with people, consider opinions, and all that. I'm all for that - 100%. But the dev's appeal to superiority in their "They should get a degree" response smacks so heavily of superiority, they've forgotten why they're in this place.

Even the best people, when they get frustrated, burned out, tired, etc. can make comments like this, but it's not out of line to call someone on it. Do it privately (don't shame them in front of everyone - that's completely the wrong thing to do), but people have to act like adults. I know that's a loaded position ("act like an adult"), but seriously people - you're in this together, right? No one person or group can hold all the power and expect things to go on that way forever.

@normalocity I'm not convinced that was what was behind the response exactly.

At least not forever, while expecting everyone else to simply be happy with it.

But you're right, the response itself does need to be addressed.

Well, I'll admit that I'm totally reading into that, you're right.

I was pretty flabbergasted with his response and made sure he was aware that it was absolutely unacceptable. And then, of course, tried to turn it into a teaching opportunity and explained how the absence of any of the departments he was critical of would negatively impact the company just as much as him or our department.

If you're the technical lead, then you don't have to go all Mr. Cop on them, but leading by example includes, IMO, addressing issues like this and appealing to the higher purpose of the organization, so to speak.

@JacobG it sounds like the attitude from your devs is a bigger problem than the flex time

@JacobG It may have been poorly worded but not so poor in intent. The dev probably feels attacked here by people who he thinks don't understand him.

The devs that have a problem with the start time thing most likely think it is being imposed by people who don't understand how work can get done other than in traditional hours.

Of course, that's all completely beside the point.

There have been other statements made by this same person that indicate a superiority issue.. (e.g. "I could interview any candidate for any open position in this company and make a better hire...")

The problem seems to be that the work isn't getting done.

@Andrew yeah, that's the core problem

My big frustration is that I feel like I have been leading by example - I show up at a consistent time, I communicate effectively to the other teams, I do dev work as well and get that done, I schedule projects and coordinate with the other departments, etc... I've done this at three other companies and been successful with this strategy always. I'm just kind of at a loss for other strategies to turn things around here...

I've used this strategy many times for so long now, I didn't expect it not to work ;)

picking the best way to address it is the hard part - like i said you've got a bunch of spoiled kids (developers) who are having their candy taken away now.

@JacobG Keep in mind that you're dealing with different employees and a different culture. Don't expect what worked elsewhere necessarily to work here.

If the developers can't act responsibly on flex time and coordinate with the other departments taking it away might well be the thing to do -- I'd have that mandate come from the corporate leaders rather than from you though @JacobG

@voretaq7 I'm actually not even sure I'd bother taking away the flex time, regardless of who it comes from. The response will be the same.

The core issues are that the people can't work together and that work isn't getting done. Those issues are not going to be solved by eliminating flex time.

If the devs can't be responsible for showing up on time for meetings with other departments, that's a big problem.

That's totally separate from flex time, though.

Well, the flex-time (core hours) was intended to be a small thing to start the ball rolling at fixing the other things... It's very likely I picked the wrong thing :(

If the dev can't manage to get work done and can't manage to work with other people, further action needs to be taken.

@JacobG That happens -- you didn't know in advance what would happen.

Now, if there is a planning problem coming from the other direction (say, from the designers), that must also be addressed.

Say, if a task could have been given the day before but wasn't, that's a problem.

But, maybe that's not actually occurring.

I do sympathize. It sounds like you're caught in the middle of some more serious problems in your company.

You may have to set some tough standards about communicating with other departments and about getting work done. If there then turns out to be an issue with deadlines that are actually too short, that's a different problem altogether.

The lead designer and I are on the same page. He and I coordinate projects and ensure that one team isn't being held up by the other. We speak regularly and plan things out against their other, non-dev related deliverables. It's the smaller, blocking issues that become a problem

You have dev experience. What happens when a thread gets blocked by I/O?

Move on to another thread, right?

But, there's a loss of efficiency.

Right .. I'm working on cross-training in the dev team as well to ease those kind of switches as there has been a real specialization problem.. Lots and lots of problems.

Just jumped back in - yeah if work isn't getting done, and you've tried it their way, I mean, isn't that proof that is doesn't work.

@JacobG Specialization is a problem, but in this case, it might actually help you solve other problems somewhat.

Just to jump back to the superiority thing for a second, I've had people I've supervised give me the superiority thing. In one particular case that person was, IMO, producing superior work, but that didn't make them a superior human being, and I had to call him on it.

Luckily we were pretty close, and I could just say, "Dude, do you have any idea how full of shit you are right now?" and that worked.

I definitely sympathize with you as well.

If you have specialization, you might be able to (temporarily) pair a dev with a designer for a project. That simplifies things a little because you can then set the expectation that those two people must figure out how to work effectively together. They will have to set their own communication guidelines, times for meetings, expectations for who does what when, etc.

If the dev can't handle that, and the designer clearly can, you then have something really concrete to use to say "um, look, you aren't getting the job done here, so [insert consequence and/or termination here]."

I really like that idea.

Actually, I guess this works without specialization too, but specialization makes it a little more obvious who should be paired with whom.

If there is a "culture war" between devs and designers generally, and it sounds like there might be, this may help -- but keep in mind that in such a clash, both sides are contributing to the problem.

You're a really small company, and you know you can't afford these kinds of problems.

So, you may have to deal with both departments at once (along with the manager for designers, of course -- as one "management team," if you will).

Well, there's really a culture war with all of the departments and dev. The design was just the most convenient example. After I got a feel for the culture of the dev department, I met with all of the other leads and asked them to tell me about the dev department. I was able to correct some of their mischaracterizations, but others were spot on and continue to happen. Let me generalize this with a scenario...

We have an internal piece of software that is used exclusively by a team of 4 people to manage and manipulate the production data used by our public facing software. We had a project to add some new information and functionality to the public facing environment. When I planned and assigned the project, I included specific tasks to document how the new feature was managed in the internal software and a training session for the team of four users so that they could ask questions.

All of this was the responsibility of the developer implementing the feature. (small company == many hats) ... He did not do the document, he did not do the training and yet he released the feature (a problem that has since been addressed).

His reasoning was "It's more important to spend time on features than internal stuff..."

I lost my point while I was typing that up

:) -- That happens.

How did the situation create/further/exemplify a "culture war?"

Well it certainly reinforced the opinions expressed to me by the other dept leads

OK, so you have department leads making generalizations about the dev department?

...the opinions that the devs don't consider the needs of others?

The devs, or this dev in this instance?

In your example, clearly, the dev did not finish the job correctly.

He did not complete all the assigned work.

That is one scenario that has happened 3 times since I've been here with 3 different devs... In all cases they tried to justify it by specific work not being "customer facing"

*justify it by saying that specific work was not...

OK... there is a concept problem, then.

The devs may have a legitimate point that they feel not all the work contributes adequately to the business.

Time is scarce, and it needs to be allocated carefully.

But, I have a feeling they aren't thinking that way.

And, the time to address that is in the project planning (which it sounds like the devs were not a part of -- that should probably change), not once requirements have been made and assigned.

The "customer" is whoever is using the software.

Internal or external, it needs to be quality, and it needs to meet the business needs.

The needs of the internal customers here were not met.

Also, it's possible that the devs were specifically told in the past not to "waste time" on some things for internal customers. I don't know. Regardless, you'll have to clarify that this idea is unacceptable and must change.

re: planned and assigned -- I do preliminary requirements gathering on projects and work with senior mgmt to schedule them. The full dev team sits down every couple of weeks and volunteers for projects on the queue... I provide them with high-level requirements and some "must do" items and then facilitate getting the additional details and coordinating work needed from other departments.

Contrary to some opinions, better devs do care quite a lot about business value. Their jobs depend on it, and they don't want to waste time on projects they feel lack that value. But, they're not always in a position to understand what that value is.

Absolutely agree with you there.

Solving the business problem with technology is much more interesting to me than the technology problem itself.

@Andrew They're users, not customers :) Care about all your users, not just the ones giving you money (directly)

They won't want to do what seems like busy work. But, if the (internal or external) customer can't use the software because the dev did not do the required documentation or training, then the development work wasn't useful, and it was all wasted time. If the devs can't see that, there is another problem.

@BenBrocka Right... I wasn't intending "customer" to mean "someone paying for the software." Perhaps "user" is a better term here, then.

Yeah, this chatting has made me realize that I was getting too focused on the punctuality. I really felt that getting them to recognize the importance of being present and available would contribute to improvements in all of the other arenas. It might be time to try and different tack.

*a different

Regarding the "culture war," though, regardless of the mistakes, laziness, etc. of the developers in the past, an environment in which they are all seen as undesirable and uncaring is not only inaccurate, it is bad for business.

@JacobG Hey, you're trying. You've asked for help. That's more than a lot of people would do. And, I think you're about to find out that dealing with the real problems is actually harder than setting rules about punctuality. But, for your business, the end result should be worth it.

It's made me realize that I've been really lucky with the previous three tech lead positions I've held ;)

@JacobG Maybe, maybe not. You may actually find out that going through this struggle produces a better team of developers in the end.

They just work differently than you're used to, but if the differences end up being because they actually care about what they're doing and about doing it well, you'll find a way to tap into that to make it work.

Or, maybe some of them are just lazy and you'll end up putting them back on the job market. I hope not, because that's no fun for you or them.

Or your company.

Best of luck to you. You'll need it. :)

:) Thanks

Yeah, good luck Jacob.

Anyone know where the site blog is, or if it's not yet in existence, where it will exist?

Don't all SE sites get a blog?

@normalocity They do if they get enough people trying to make a blog and other factors. It's not automatic

I don't know if there's a limit on how early you can get a blog but you might wnat to bring it up on Meta if it's something you're passionate about

If we had one it'd be at blog.sitename.stackexchange.com

Cool, I figured as much (tried that url). Thanks

I might be interested in being a part of the blog. I've written a blog about this kind of stuff for a while, so it would be natural to put my efforts toward this instead. I'll post it on meta.

I was tempted to be a part of the UX blog but we never ended up making one. Never run a blog either

@BenBrocka "and other factors" = "Send the community team good booze." ?

haha - what sort of booze do they like, and where do I ship it? :P

@voretaq7 well, cheap booze certainly wouldn't help your case

@BenBrocka Right, we'll clean the bathtub before we make your hooch then.

@JacobG Re: core hours, the way you're putting it the "core" of 9:30-4 is effectively a normal 8-hour day. You're basically telling your people who like coming in late that their hours are 9:30-5:30.

hey @HLGEM

It does seem as if the core problem is that the developers are immature and don't respect the manager. People need to knwo there are consequences for bad attitude. If you let this slide then they won't respect any decision you make. I would rather have a developer who is a team player than these yahoos you are describing even if they had awesome skills.

@HLGEM yeah, it's not even that they don't respect him as a manager, they seem to have no concept of "Your actions are bad for the company". Flex time and the like only work if you "flex" in the company's favor - if it's just "I wanna come in late and to hell with the deadlines" someone's bucking to get fired...

Agree, unless these developers are somehow irreplaceable with skills no one else inteh marketplace has, I'd replace them.

@HLGEM I'd make sure to have a good talk with them first about the specific, underlying problem.

You can't just fire everyone until someone does it right either