Tag: management

Open space office kills productivity by 66%

While going through this article on noise pollution, I came across this:

If you can hear someone talking while you’re reading or writing, your productivity dips by up to 66%.  Open floor-plan offices distract workers without them even noticing it. In a classic study published in the British Journal of Psychology in 1998, researchers found that employers were highly distracted when they could hear conversation around them, and less able to perform their duties. Another classic study found that noise in the office also correlated to increased stress hormone levels and a lower willingness to engage with others. According to Sound Agency case study, when sound masking technology was used in an office, there was a 46% improvement in employees’ ability to concentrate and their short term memory accuracy increased 10 percent.

Most of the time through my working years I’ve spent at open space offices.  And here are the things I have to say about them:

  • I tend to hate them.  There were companies and teams and offices where it worked well and made sense, but those were exceptions. Most of open space offices are there for one and one reason only – cost reduction.  And that feels!
  • Noise pollution is a factor.  Some people cope with it better (naturally or via headphones with music or white noise), but I am not one of them.  I find it nearly impossible to concentrate when there are other people around.   Even if they don’t talk, they still move, and make noises.
  • Open space offices do help to improve collaboration, team building even sometimes.  Again, not something that works everywhere, but I’ve seen it more than once.  When the team members are not too far away from each other, and all of them work on the same sort of things, and once the chemistry of the group gets going, open space can be quite handy.
  • If the company doesn’t notice a 66% productivity reduction in an employee, it can probably afford it.  Chances are, it will probably have no idea how to handle the guy at the top of his performance.  It’s almost funny, but I’ve seen it happen before.

I don’t have a silver bullet solution to the problem yet, but I do like the recent trend of companies that care about people’s productivity, offering a combination of offices – open spaces, closed offices, meeting rooms, playrooms, etc.  That’s probably not ideal either, but having the choice is nice, I guess.  Now, if only there was a cheaper alternative…

 

Marissa Mayer Has a Secret Weapon

Marissa Mayer Has a Secret Weapon

Fascinating!

For the past decade, she has been the doyen of a collection of some of the most talented young engineers and product managers in all of technology. These are the hand-selected prime talents of an accelerated leadership program at Google called Associate Product Manager (APM).

Mayer invented this program, led it and never gave it up. It was a key part of her tenure at Google. And now she may reap some benefits.

Don’t be fooled by the modest title, prefixed by that timid word “associate.” The most coveted entry post at Google is spelled APM. This is an incubation system for tech rock stars. “The APM program is one of our core values — I’d like to think of one of them as the eventual CEO of the company,” Google’s Executive Chair Eric Schmidt once told me.

Consider the first APM, a fresh Stanford grad named Brian Rakowski. He became a key leader of the team that built the Chrome browser and now is the VP of the Chrome operation. The second was Wesley Chan, who made Google Toolbar a success, then launched Google Analytics and Google Voice. He’s now picking winners for Google Ventures. Another early APM was Bret Taylor, who earned his bones by launching Google Maps. He left Google and co-founded Friendfeed, then become the Chief Technical Officer of Facebook.

Though not all APMs achieve such glory, they are generally recognized as elite. At any given time at Google, there are over 40 APMs active in the two-year program. And since Google has been hiring them since the early 2000s there are over 300 who have been through the program.

And the glue to the whole shebang was Marissa Mayer, who was the APM boss, mentor, den mother and role model.

Mayer thought up the program in early 2002. Google had been struggling to find PMs who could work within the peculiar company culture — team leaders who would not be bosses but work consensually with the wizards who produce code. Ideally, a Google product manger would understand the technical issues and sway the team to his or her viewpoint by strong data-backed arguments, and more than a bit of canny psychology. But experienced PMs from places like Microsoft, or those with MBAs, didn’t understand the Google way, and tried to force their views on teams.

So Mayer came up with an idea: Google would hire computer science majors who just graduated or had been in the workplace fewer than 18 months. The ideal applicants must have technical talent, but not be total programming geeks — APMs had to have social finesse and business sense. Essentially they would be in-house entrepreneurs. They would undergo a multi-interview hiring process that made the Harvard admissions regimen look like community college. The chosen ones were thrown into deep water, heading real, important product teams.

On having resources

I found this excellent illustration somewhere in my social networking streams.  Don’t know who is the author, but this is absolute genius.  Until now, I’ve been using a rather outdated example of “brand new Pentium IV computer to play solitaire“.   This one is so much better though.

Project management tips from Linus Torvalds

Linus Torvalds shares some of his thoughts on software project management in this interview. I have two favorite bits in there. One is on the obsession of the code quality control:

“The other thing—and it’s kind of related—that people seem to get wrong is to think that the code they write is what matters,” says Torvalds. Most software development managers have seen this one. “No, even if you wrote 100% of the code, and even if you are the best programmer in the world and will never need any help with the project at all, the thing that really matters is the users of the code. The code itself is unimportant; the project is only as useful as people actually find it.”

Just a few years ago I would have completely missed this point. Or argued passionately with it. But not anymore. After spending the last few years working with very dynamic software projects, I realized that no matter how much effort you spend on the code quality control, it will still degrade with time. And even if it becomes horrible and hard to look at, it will still work and you’ll still be able to maintain it. But the time and effort that was lost would have been so much more useful in supporting user requests and improving their experiences.

Even knowing this now, I am still a slave of my habits. I still need to control myself, set tight deadlines, and learn to ignore a lot of things that would have caused me a heart attack back in a day.

The second point that I found interesting in the interview is similar.

I also asked Torvalds about Software Configuration Management (SCM) tools like his own Git version control system. He replied, “I don’t think tools are all that fundamentally  important.”

“Now, what is important is that there’s a good workflow for the project, and tools can certainly help with that,” said Torvalds. “But most projects don’t necessarily really need tools. There’s a lot of projects that simply don’t have enough changes to really require any tools at all for their work flow; if you only have a few hundred patches per release, you can maintain those just about any way you want, including entirely by hand.”

Again, a few years ago (and even sometimes now) I would argue and fight for the perfect setup and ideal toolbox. These days I seem to care less. As long as the work is being done and the project is moving on, I don’t really care which tools are being used. I have my preferences, of course, and I would try to push them through to be used by majority of participants, but I am much more relaxed on this subject than I used to be.

One other thing that I wanted to mention is the difference in perception. In Linus’ world, it seems, changes are always distributed as patches. To the effect that it would even be considered a specialized tool – everyone is using it. And I understand – all of the people with who he works are very experienced technical people and there is indeed no other way. But for the rest of us things aren’t as rosy. On several occasions I worked in a team where people weren’t using any tools. Literally. They had no idea about patches, diff, scripts, merging, version control, any of that. Changes in those projects were maintained by hand. And there would be nothing similar in concept to a release. Which didn’t help.

There was indeed one particular project.  Do you know how I remember it?  I was at one of those PHP conferences somewhere in Europe. And one of the talks I attended was on how to use unit testing during the re-factoring process.  The presentation was filled with examples of ‘horrible’ code which was then surrounded by unit tests and later re-factored into better code.  The code that was presented as ‘horrible’ was some of the best code I’ve seen in my life!  After the presentation I came up to the speaker and showed him the project with which I was involved, which had some truly horrible code.  You should have seen the look on his face… It took him a couple of minutes to compose himself and start thinking on how to work with that nightmare.  He even thanked me and promised that we would include some examples of that crap in the future versions of his talk.

My point here is the difference in perception.  When Linus says that things can be done without any tools at all, and when that guy talked about horrible code, they both, I think, are somewhat spoiled by their surroundings.  I’m sure not everyone even would be able to make sense of a gadzillion tiny little things that Linus uses on a daily basis and doesn’t even consider them as full featured tools.  I’m sure not everyone even would be able to read some of that ‘horrible’ code the other guy spoke about, let alone write something like that (I remember it being OOP, with comments, well-tabulated, etc).  There is a certain minimum level which has to be there.  That minimum level is assumed to be a zero.  But it’s not always there.