Hacker News Reader

Comment by edw519 | Hacker News Reader

Everything we do to manage a business consisting mainly of remote employees is something anyone else could do too.

I would modify "anyone else" to "anyone else enlightened enough". Big difference.

It's still amazing how many managers/leaders are so bad at managing/leading that all the tools in the world wouldn't make a bit of difference. You know who they are, the people for whom:

  perceived activity = progress
  meetings = progress
  being there = progress
  lines of code = progress
  check marks = completion
  social skills = competence
  perception = reality
  what's on the surface = what's underneath
  # of tasks completed = an acceptable metric
  successful testing = quality software
  smiling customers = satisfaction
  90% complete = only 10% more to go

Good managers know better. So they can take advantage of OP's tools.

The technology for managing remotely is clearly ahead of the people who would most benefit from it. I look forward the the day when managers catch up and "get it".

View on HN

I look forward the the day when managers catch up and "get it".

So do I, but telling a corporation whose entire culture is built around facetime to "catch up and get it" is, in the general case, like walking up to a flightless bird and waving your arms and shouting "fly, you fool, fly! Don't you realize that the future is in flying? Your cousins that can fly are made of the same parts as you; rearrange them and fly!"

As PG memorably put it:

http://www.paulgraham.com/opensource.html

When I say business can learn from open source, I don't mean any specific business can. I mean business can learn about new conditions the same way a gene pool does. I'm not claiming companies can get smarter, just that dumb ones will die.

I look forward for when techies "get it." IRC and iChat are poor replacements for real human interaction. You can certainly work with them and even be successful with them. But rarely do you approach the same team cohesion you get with in-person facetime.

I think some mix is good. In the office 2-3 days a week and remote the rest of the time. You get a good social balance and then the freedom to work from home.

Incidentally, everyone I've come across that refuses to meet that balance takes on a weird sense of entitlement, illustrating they'd probably be a poor fit anyway. I'm sure there are mitigating circumstances for that, but it is off-putting to the whole idea.

(I don't disagree with this, by the way. The perfect culture that supports the perfect balance of personal and remote interaction is a dream that one aspires to, not a goal one necessarily expects to attain in one's lifetime. ;)

I think the balance really is important. What we've found is that just meeting up 3-5 times a year does the trick for us. We don't need every week.

I have worked for several years on remote teams and have a couple years work experience on a completely local team. In terms of team cohesion I'd say that it has very little to do with colocation, all other things being equal.

Maybe you just haven't worked with a cohesive fully remote team ever?

I certainly haven't. Isn't it incredibly rare?

I wouldn't want to rule that possibility out. But I've worked with people remotely for years and known very little about them. Because our communication is almost solely work-related. Whereas the people I work with locally I know very well. We go out for lunch or for drinks. We chat about random crap in the office. It's not really work, but from it I learn how to work with those people much better.

I'm not doubting you, but can you provide actual examples of how this has resulted in a better work product?

I don't doubt that working together physically has benefits for feeling closer to your coworkers. But I do wonder if that actually has solid bottom line results. And do those results outweigh the benefits of have more talented and productive teammates who are not in the office?

When I'm stepping back to take an objective look at it, "team cohesion" is one of those things that could easily have more value ascribed to it than it actually provides.

Software quality is a notoriously difficult thing to measure. Most studies are conducted over large codebases over several years (IBM & Microsoft have spent a lot of time on this). So, I can't actually prove it.

I have spent a lot of time dealing with it and I know what I'm most comfortable with. And there are always exceptions. I've worked with some really talented remote people -- oddly, they usually end up relocating eventually anyway because they want to. I've also worked with some remote people that really think they're much better than they actually are.

Professionally, the least satisfying jobs for me are the ones where people clock in and clock out. They may be very efficient, but I usually don't learn much from them and there's zero contact after we invariably go onto our next thing.

That's a long-winded way of saying you might be right and objectively team cohesion is overrated -- I really don't know. Subjectively, I found I'm happier that way and I do my best work when satisfied. I do believe it's resulted in higher quality products usually, too. It's often the stuff you don't think about. Like overhearing a couple colleagues discussing something and being able to interject and save them a couple days of frustration. That stuff usually doesn't land in IRC, Basecamp, Skype, or whatever.

But if you've managed to make it work, awesome. It's not my intention to combat the practice if it's working. I just don't like the attitude that anyone opposed to it is some sort of Luddite that sucks at business.

I agree. I've worked for years, sometimes with people that I've never met in person, and had great working relationships while learning very little about their lives. I enjoy having separate work and social lives.

It's funny because this is the antithesis of my experience. A few of my best friends I met through remote teams. One of them I knew for years, and we finally met in person, in Raleigh at the IBM campus. IT was funny because it was a little awkward at first and then we fell into old conversations just like we did on Skype. For every project we have a group chat on Skype and we encourage tech talk and friendly banter. Some of my best friends in the world I have never met in person and I know a good bit of personal detail about them. I have found the experience to be exactly the same as being in a collocated area.

I've actually found IRC can be a helpful addition even when you're physically in the same place. Supports different kinds of discussions that can be useful, especially asynchronous ones, or ones where one or both people find it useful to refer to documentation while chatting.

Agreed. It's a great way to share reddit links.

I have to chuckle at this.

I was an admin in a freenode channel at the time reddit (the one page lisp version) launched.

It initially boomed as it was a great way to share IRC links . . .

I find more the opposite; RL chat is used for fluffy taking-a-break type stuff (take off a few minutes to go the coffee machine and talk about your weekend), while real work starts once everyone gets back to their desk and puts on headphones, using IRC or IM as a unobtrusive backchannel to discuss the stuff we're working on. Works nicely with collaborative document writing in Google Docs as well.

I've tried an "everyone in the same room" approach to collaborative document writing a few times, and that was a disaster for >2 people; online just works much better. Though IRL can sometimes work if it's exactly two people collaborating, who work well together, sharing one keyboard in the style of Extreme Programming (whether on code or prose).

The cohesiveness of a team has little to do with the number of hours they spend in the same room. It's much more related to the composition of the team and how much they share/agree on the purpose of what they are doing.

If you have a bullshit product, no amount of duct tape will hold the team together. On the other hand, a great, world-changing idea is enough to drive the team, keep it cohesive and push its members to levels they wouldn't normally reach.

DHH and his team have a world-changing idea to play with, one that has legs of its own.

If you work with shitty people on a shitty product, you'll have problems locally or remotely, for sure. I'm working on the assumption that people are competent in their job and working on a good product. I still don't buy that a Skype conversation is going to afford more camaraderie than grabbing a beer at lunch or playing a game of ping pong. It's that whole company culture thing. It's the difference between people I work with and those I kick ass with.

You don't need camaraderie - you need a shared purpose and team play. They don't have to be friends - all they need is to respect and trust each other within the limits of their professional activities. Skype conversations have nothing to do with it except, perhaps, helping establish the mutual recognition more easily. Textual communications may become abrasive or be interpreted that way.

I'm happy to agree to disagree. Maybe you're the most successful bastard on the Internet and you have a formula that always works. We're obviously looking for different things and drawing from different experiences.

But as much as it sucks, it almost doesn't matter if you're right. The perception is you're arrogant enough to tell a company or a team how it should be run and if they don't meet your terms, they're doing it wrong and you're going to go do your own thing (this is the royal "you"). I'm exhibiting a mentality you wouldn't want to work for, you're exhibiting a mentality of someone I wouldn't want to work with.

You don't have to agree with any of my rationale, but it may help you and other remoters to understand it. Perhaps it'd help to generate a more compromised view than the "you don't need" responses I usually see. And if it helps with context at all, I've experienced this as a remote employee, a local employee with remote colleagues, and an employer.

Trust me and, more important, trust your team. They are on your side and know what to do. Just encourage them to communicate and they will probably be able to arrange it. They'll do the right thing.

As for me, my current job involves being in the office - the company, the portal branch of a telco, doesn't believe in telecommuting just yet, despite us techies pushing for it. We have lost a couple good people over that issue and it prevented hiring several others I'd love to have on my team. In the past years, I have been involved in several projects that were conducted without physical presence and most of them worked just fine. Keeping everyone on the same page is critical and the least successful ones were when communication was difficult.

I don't know about you but chatting through IRC and Skype is real human interaction to me. The experience is not certainly fake.

With regards to team cohesion, there is no guarantee that you can have achieve that with in-person teams. But the bottom-line here is that do you want to have the best talents working for you or not?

I can't agree with you more.

But let me briefly offer an insight about why I think things won't change: management itself exists to perpetuate the things on the left hand side of your equations above.

Traditional managers in established (i.e. large) companies are terrified of letting their staff work from home because they perceive (correctly) that if those staff are still productive then there isn't really any reason for them to be employed in their own role.

The things on the left hand side of your equations are a proxy for success that the manager can use to justify their own usefulness. As soon as you start measuring "real" progress the need for non-productive members of staff disappears entirely and most middle management instantly becomes surplus to requirements.

The idea that management exists to perpetuate the things on the left is as cynical and generally wrong as the idea that coders exist to increase complexity and guarantee their own necessity. It is true only of the worst of either group of people. The best work hard to make themselves unnecessary.

>coders exist to increase complexity and guarantee their own necessity

Holds true in more cases than not, at least in my experience in the enterprise. "Writing your own X" when off-the-shelf solution is available is a dominant example of this.

In many companies the same rigid structures that allow them to operate with average and below-population-average employees reward those who can game them andreduce their own output to the lowest levels toleraed by the structure.

I have freed many good programmers from this trap, but not nearly enough and many remain to be saved.

I've seen the very worst managers a lot more frequently than the very worst programmers. While some structures may reward bad programmers, structures far more frequently reward bad managers and very often prvide them with a place to hide their inadequacies very easily.

That's because if a programmer is bad, work doesn't get done, and people notice immediately. But if a manager is bad, the subordinates often manage to get work done despite the manager, and the bad manager is in turn more likely to have a bad manager who doesn't recognize the on-going failure.

I don't have much experience with managers because I freelance now and I've never worked at a company with more than about 80 or 100 people.

So this is a real question and not snark... Assuming large companies continue to exist, how do you run one without managers?

If your company is 1000 people do have 10 executives and 990 engineers, customer support, etc. and no managers at all? How does everyone communicate? How do the executives delegate?

Do you need some managers? How many per worker is optimal?

It seems like every large corporation in existence has managers. I can't think of any exceptions. So I'm not sure what an alternative would even look like. Perhaps rotating temporary management structured like jury duty?

I'll probably be downvoted because bashing management is a time honored hacker pastime... But I really am curious. Is it possible to do away with management? Is it desirable?

Oh, you definitely need some managers. I'm not suggesting that we should do away with them completely :-)

In the past (i.e. prior to what we sometimes call "the information age") it was a perfectly reasonable thing to have a very tall pyramid shaped hierarchy within a company. This was because the people at the bottom of the hierarchy needed to be told what to do and how - i.e. the manager was the "expert" at some task.

Nowadays people at the bottom of the hierarchy (especially in technology) tend to know exactly how to do their jobs - in fact they know much more than their manager about their own specialty. This has led (in savvy organisations, at least) to much flatter hierarchies.

> Do you need some managers? How many per worker is optimal?

http://en.wikipedia.org/wiki/Span_of_control

"In the hierarchical business organization of some time in the past it was not uncommon to see average spans of 1 to 4 or even less. That is, one manager supervised four employees on average. In the 1980s corporate leaders flattened many organizational structures causing average spans to move closer to 1 to 10. That was made possible primarily by the development of inexpensive information technology. As information technology was developed capable of easing many middle manager tasks – tasks like collecting, manipulating and presenting operational information – upper managers found they could hire fewer middle managers to do more work managing more subordinates for less money."

Do you really think that managers 80 years ago knew more about task X than the people they managed who did task X every day? I think software/info people like to think our situation is different, but I don't suspect it was all that different in the past. What may be different is that today we have the ability to get a lot more information at our disposal about what's going on in a company than people did 100 years ago.

I think technology has allowed people at the bottom of the pyramid to "own" larger pieces of responsibility within a company, thus allowing them to operate much more independently.

In the past this really wasn't the case. An entire discipline called "Scientific Management" sprung up to explain why workers should be treated almost like animals by management:

http://en.wikipedia.org/wiki/Scientific_management#Taylor.27...

I think this knowledge inversion where the "individual contributors" know more (about the job) than the manager is why many managers do not like agile methodologies like Scrum. Developers are "seizing the means of production". ;)

When developers can work directly with product owners and track their progress, the traditional manager loses. I'm not sure how a developer-driven team might handle HR issues though.

I'm not sure how a developer-driven team might handle HR issues though

There is a nuance here that is being missed, there is management and there is administration, management is authority and administration is coordination among contributors to keep the production line running. Many organizations mistake the two for the same roles as such they give to many administrators authority and make them managers. When many organizations could flatten their management hierarchy and create more administrative roles. HR is a good example of a business function that can be done via administration and not authority. The funny part is when you make people administrators they see themselves more like contributors and become less threatened by efficiency.

Thanks for the clarification. Is the administrator role you describe something like a program manager (PM) or scrum master?

Would you say a "tech lead" is a manager? They have (technical) authority of the product, but not necessarily hiring/firing of other people.

I generally consider leads and architects to be administrators same with project managers, if fact in a good deal of organizations that I have been a part of we did not call them project managers, we called them project coordinators or project liaison which better reflects the role.

You should read some Rands in Repose about the point of the manager job role.

Not every company has this fear. In fact, some large companies are the most progressive with the ability to work remotely and have a huge investment in infrastructure to support this. On the negative side, the employees become more replaceable in the minds of many execs. This includes project and middle managers, so it's not just on the leaf developers.

Agreed : out of sight = out of mind. It's a -lot- easier to think of remote workers as a pure commodity.

Indeed. Some people believe that there's no real productivity gain from all team members being located in the same place. However, one of the (potential) benefits of being located in the same place (as management) is job security. People grow attachments to others.

Plausible if you accept that problems can be broken into separate pieces. Furthermore, measuring/comparing the productivity is non-trivial/impossible.

At my previous employer, a high* level manager (3 levels above me - a leaf node developer), considered it his job to just shield his subordinates from demands/bullshit of those above him.

That's definitely a desirable quality, and leads me to believe he'd have other desirable qualities.

* In reality, middle management, but at the level where strategic decisions are made/strongly influenced.

This is an unpopular opinion, but I completely disagree.

Great people + perceived activity + being there + lines of code + check marks + social skills = happy customers (usually).

Mediocre people + perceived activity + being there + lines of code + check marks + social skills = waste of time/money (usually).

Great people - (perceived activity + being there + lines of code + check marks + social skills) = happy customers => unicorn scenario (usually).

In an ideal world your great people give you acceptable deadlines and consistently deliver high quality software on time. Then you can ignore subjective metrics like time in office, perceived activity, etc. and everyone is happy. This happens once in a blue moon.

Most of the time when great things happen people happen to be in office, they look like they're working, and they produce a ton of code. Of course correlation is not causation, so forcing people to produce lots of code and be in the office won't necessarily get you good results.

Engineering management is really hard. Please don't trivialize it with feel-good nonsense.

    social skills = competence

If you haven't got 'em, I don't care how competent you are. One bad apple can poison an entire team. Developing software is a team sport.

Interestingly I've found this not to be the case, many very good teams of coders (in my experience) have at least one socially awkward person, and still perform very well. (Sometimes it feels like the manager is little more then "socialable" face of the team.)

On the other hand, I find that attitude matters a lot, and one even mildly disgruntled / unmotivated person can really sink a team.

Oh, I agree -- I had taken social skills to mean "plays well with others."

Awkward is just fine. Someone who is mean or lazy is another story.

That's not social skills, that's attitude/decency and work ethic.

Asking coders to increase social skills is asking them to dilute who they are. Like many actors and singers, they lose who they are because they become mixed up with everyone else. Some don't, I don't imagine seeing Johnny Depp schmoozing in a totally social scene, maybe with a few carefully chosen people he trusts and in a quiet location.

Not all programming positions require the same amount of social skills. Some jobs are just fine for the "antisocial software genius" type. Just don't make me work with those guys.

My problem with this is that a lot of programmers/hackers/etc. are pretty good at interacting with each other, but maybe not quite as proficient at interacting with the rest of the populace.

Like for example when you're in the middle of working and someone comes to talk to you, maybe you're just so focused on the problem that you don't realize they're there or you don't want to draw your attention away from the problem, and then that person sees it as disrespect and signs of social awkwardness, while you're just trying to get your job done.

Or if you're in the middle of trying to solve a problem and you ask someone bluntly for something (because you're so focused on the problem) and they take it the wrong way.

I'm not saying that a complete lack of social skills is good either; just maybe that the target of these social skills is the manager, or the sales people, etc. and not the people you're doing all the work with.

One bad apple can poison an entire team.

This is the second time in as many weeks that I've seen these exact words on HN...is it from a specific essay or book?

Not one that I've read.

"One bad apple spoils the bunch" is a common proverb; this is a pretty simple adaptation.

I know. I'm talking about this particular construction as applied to "teams" and in the context of "fit."

> smiling customers = satisfaction

I think they are right about this one. What's your problem with this?

Often the customers aren't the end users.

I suppose a job can't always be considered to be done well, just because the customer is provided with what they felt they needed. Sometimes the customer is asking for the wrong thing in the first place.

While I can see the reasoning behind this mentality, I have a hard time supporting it unequivocally.

Too many times I've come across what really feels like engineer / developer arrogance vis a vis their end users. The notion that the customer "doesn't know what's good for them" has a bizarrely patronizing air to it.

If the customer is happy, then the product has done it's job. Doesn't mean it can't be improved - but perfection comes after the customer has quit bitching.

"social skills = competence"

Not to nitpick, but social skills are a form of competence. I know it's not a popular notion in some circles, but communication and the ability to articulate a position is a crucial work skill.

1000% agree.

Taking responsibility is the single hardest quality to find and hire.

Allow me to add to your list.

people who makes incomplete and faulty lists of what good leadership consists of = someone we should take serious

Reply on news.ycombinator.com