Particularly the 'bring back the door' chapter.
Then realise this book was first written 30 years ago based upon research done in the late 1970s.
Tech may change rapidly but, unfortunately, people don't.
It talks about what makes a good team, how powerful they can be, and also gives some insight on team dysfunction.
Although they might base some statements on assumptions I do not fully agree with all the time, and before reading I was had not decided if I was strictly for or against open office plans, their conclusion is spot on: open plans do not foster collaboration or communication. They may cause a constant buzz and seem productive, but nobody will be smart, creative or productive in that environment, compared to a silent, uninterrupted workplace.
All you multitaskers and procrastinators (including me): You are lying to yourself.
What worked for me:
- One on Ones. Nothing I've done has had as much of an impact as weekly one-on-one meetings with everybody on my team. I tend to follow the format outlined on Rands In Repose: http://randsinrepose.com/archives/the-update-the-vent-and-th... (This is an incredible blog for engineering management. I would highly recommend reading everything he has written.)
- Read everything you can find on the topic and about leadership in general and start figuring out how you can incorporate the lessons from those books into your situation and context. This is a brand new skill set that you need to approach with the same effort that you had been approaching engineering.
Rands in Repose: http://randsinrepose.com/archives/category/management/
Radical Candor: https://www.amazon.com/Radical-Candor-Kim-Scott/dp/B01MY574E...
Extreme Ownership: https://www.amazon.com/Extreme-Ownership-U-S-Navy-SEALs/dp/B...
Becoming a Technical Leader: https://www.amazon.com/Becoming-Technical-Leader-Problem-Sol...
- Finally, one piece of advice I got when I first transitioned into management was that "first-time managers usually fall into the trap of becoming the manager they wish they had. What you really need to do is figure out how to be the manager that each person on your team wishes they had, and become that manager." Easier said than done, obviously, but I've always found it useful to return to it whenever I am struggling.
A Pattern Language, Alexander and Ishikawa and Silverstein http://amzn.to/2s9aSSc
Advanced Programming in the Unix Environment , Stevens http://amzn.to/2qPOMjN
Algorithmics: the Spirit of Computing, Harel http://amzn.to/2rW5FNS
Applied Crytography, Wiley http://amzn.to/2rsULxS
Clean Code, Martin http://amzn.to/2sIOWtQ
Clean Coder, Martin http://amzn.to/2rWgbEP
Code Complete, McConnel http://amzn.to/2qSUIwE
Code: The Hidden Language of Computer Hardware and Software, Petzold http://amzn.to/2rWfR9d
Coders at Work, Seibel http://amzn.to/2qPCasZ
Compilers: Principles, Techniques, & Tools, Aho http://amzn.to/2rCSUVA
Computer Systems: A Programmer's Perspective, O'Hallaron and Bryant http://amzn.to/2qPY5jH
Data Flow Analysis: Theory and Practice, Khedker http://amzn.to/2qTnSvr
Dependency Injection in .NET, Seemann http://amzn.to/2rCz0tV
Domain Driven Design, Evans http://amzn.to/2sIGM4N
Fundamentals of Wireless Communication, Tse and Viswanath http://amzn.to/2rCTmTM
Genetic Programming: An Intrduction, Banzhaf http://amzn.to/2s9sdut
Head First Design Patterns, O'Reilly http://amzn.to/2rCISUB
Implementing Domain-Driven Design, Vernon http://amzn.to/2qQ2G5u
Intrduction to Algorithms, CLRS http://amzn.to/2qXmSBU
Introduction to General Systems Thinking, Weinberg http://amzn.to/2qTuGJw
Joy of Clojure, Fogus and Houser http://amzn.to/2qPL4qr
Let over Lambda, Hoyte http://amzn.to/2rWljcp
Operating Systems: Design and Implementation, Tanenbaum http://amzn.to/2rKudsw
Parsing Techniques, Grune and Jacobs http://amzn.to/2rKNXfn
Peopleware: Productive Projects and Teams, DeMarco and Lister http://amzn.to/2qTu86F
Programming Pearls, Bentley http://amzn.to/2sIRPe9
Software Process Design: Out of the Tar Pit, McGraw-Hill http://amzn.to/2rVX0v0
Software Runaways, Glass http://amzn.to/2qT2mHn
Sorting and Searching, Knuth http://amzn.to/2qQ4NWQ
Structure and Interpretation of Computer Programs, Abelson and Sussman http://amzn.to/2qTflsk
The Art of Unit Testing, Manning http://amzn.to/2rsERDu
The Art of Unix Programming, ESR http://amzn.to/2sIAXUZ
The Design of Design: Essays from a Computer Scientist, Brooks http://amzn.to/2rsPjev
The Effective Engineer, Lau http://amzn.to/2s9fY0X
The Elements of Style, Strunk and White http://amzn.to/2svB3Qz
The Healthy Programmer, Kutner http://amzn.to/2qQ2MtQ
The Linux Programming Interface, Kerrisk http://amzn.to/2rsF8Xi
The Mythical Man-Month, Brooks http://amzn.to/2rt0dAR
The Practice of Programming, Kernighan and Pike http://amzn.to/2qTje0C
The Pragmatic Programmer, Hunt and Thomas http://amzn.to/2s9dlvS
The Psychology of Computer Programming, Weinberg http://amzn.to/2rsPypy
Transaction Processing: Concepts and Techniques, Gray and Reuter http://amzn.to/
Types and Programming Languages, Pierce http://amzn.to/2qT2d6G
Understanding MySQL Internals, Pachev http://amzn.to/2svXuFo
Working Effectively with Legacy Code, Feathers http://amzn.to/2sIr09R
Zen of graphics programming, Abrash http://amzn.to/2rKIW6Q
Edit: add Amazon link.
 Crossing the chasm (Marketing related)
 Peopleware (HR related)
 How to win friends and influence people (HR related)
 The Goal (Business related)
 Critical chain (Project management related)
 Who moved my cheese (Change management related)
and any of the lean / agile businessy books for ex.
 The lean startup
These might not be viewed as traditional MBA material, but my course featured some of these along with more traditional academic books on subjects like financial management, people management, operations etc. I can provide these textbooks to you as well if you like.
*Amazon links just for convenience, no affiliation.
It had a lot more wisdom in it on teams, interruptions, flow, and so on. I recommend anyone that enjoyed this story to get it as it has many more with recommendations. Of course, my version was an older one so the new one might be better or worse. I'm sure it will be Good at the least. ;)
Demarco is great!
Some references (sorry for the formatting, if this becomes a thing I'll do the wiki and the logo):
Perl and 9/11:
Waterfall (same pdf, linking from 2 sources):
Unrelated, Pournelle's Iron Law of Bureaucracy (I just like this law):
Atwood, Don't Learn to Code:
Wason selection task:
Amazon Links, no referral:
Agile/XP practices are a good starting place in-between cowboy programming and micro-management hell -- as long as you don't take them as a recipe book. They're simply best practices that you can and should learn. Then prune/modify as necessary. There are really too many books to list separately. I'd advise joining a local Agile User's Group and noticing who has their shit in one sock. Then find out what they're doing. You can also bring in external coaches.
You need a couple of good books on the people part of things. I can guarantee you that the people part of things is where you'll screw up. "Drive" is really good. http://amzn.to/1qtZdEd So is PeopleWare http://amzn.to/1iBnasO
For strategic stuff, especially in a growing company, you're going to have to master large work queues without having them eat you alive. If you'll allow me to self-promote, my Backlogs series is geared exactly towards this problem. http://tiny-giant-books.com/backlogs.htm
One observation: as you grow, it's not enough that you pay extremely careful attention to whom you hire. You also need to create an on-boarding system where new hires can learn and adopt the culture -- things like pair programming, how the build works, good coding etiquette, and so on. Setting the table for strategy to work is actually more important than whatever the strategy is.
Second observation: I imagine you're going to be swimming in business book recommendations. Business books are like dieting books: everybody has a few favorites. (I imagine this is because the material inside matches how they already feel). Better to identify specific areas, like Agile Requirements Modeling, and find books targeting those areas. Then look for practical advice. Otherwise you'll just have a ton of books that you'll spend hundreds of hours reading and not really have much to show for it at the end of the process.
Their discovery was that people who had closed door offices were more productive. In general people with less interruptions got more done.
The book is somewhat dated, so this may have changed since, but one of the interesting things they found was that there weren't really any studies showing that open offices helped productivity for software teams. It was purely a cost saving measure by execs wrapped up in wrapping of "being collaborative".
"During the 1960s, researchers at Cornell University conducted a series of tests on the effects of working with music. They polled a group of computer science students and divided the students into two groups, those who liked to have music in the background while they worked (studied) and those who did not. Then they put half of each group together in a silent room, and the other half of each group in a different room equipped with earphones and a musical selection. Participants in both rooms were given a Fortran programming problem to work out from specification. To no one's surprise, participants in the two rooms performed about the same in speed an accuracy of programming. As any kid who does his arithmetic homework with the music on knows, the part of the brain required for arithmetic and related logic is unbothered by music -- there's another brain center that listens to the music."
"The Cornless experiment, however, contained a hidden wild card. The specification required that an output data stream be formed through a series of manipulations on numbers in the input data stream... Although the specification never said it, the net effect of all the operations was that each output number was necessarily equal to its input number. Some people realized this and others did not. Of those who figured it out, the overwhelming majority came from the quiet room."
I don't think there's a problem with listening to music some of the time. My concern is that by constantly having the headphones on to mitigate audible distractions, I'll miss insights that would directly impact the quality of the work that I do.
If, conversely, a candidate asked me the questions edw519 listed above, you'd pretty much be guaranteed a job. I don't care how well or badly you program. I don't care whether you know Boost or not. I want to know whether you'll fit in here. Ever read Peopleware ? There's a great example in there on why you should value the
programmer that seems to deliver nothing of value, and yet makes the team gel.
If you don't know why this line of C++ code compiles with Visual Studio 6, but produces the wrong result, hey, that's ok. Are you giving me the impression that you like programming? That you will try and find an answer yourself before coming to ask for my help? If I ask you a question that you can't answer, do you bullshit, or do you say "Hey, I don't know, but I'll find out and email you the answer tomorrow."
The character is far more important to me than your ability as a programmer. The former is a fit, or it isn't. The latter I can work with. Because it's a long game.
Get dozens of book recommendations delivered straight to your inbox every Thursday.