Preface
“There are no experts. There is only us.”
These two simple sentences always make me feel lonely. They were uttered by Jeremy D. Miller, a software developer and architect I’ve come to appreciate over the years. These sentences give me the feeling that there’s nobody else to turn to—that I have to start trusting my own instincts, and that whoever tells you they are an expert is either lying or wrong.
During my career, which consists of almost two decades in the IT business as of the time of this writing, I’ve come to realize that “There are no experts. There is only us” is very true. During one of my first jobs as a programmer, I joined a team working on a government project (the project was all in Visual Basic 6.0). The team, including my team leader, had no idea what they were doing, but because I also didn’t know what I was doing, I assumed that whatever people were doing was the right way to do it.
As time went by, I began to read books about how software development could work, including The Mythical Man-Month by Fred Brooks (University of North Carolina at Chapel Hill, 1974) and Peopleware by Tom DeMarco and Timothy Lister (Dorset House Publishing, 1987). I looked around and recognized all the problems those books were talking about right there in front of me.
But nobody around me said anything about the crap we were building or the crap we were taking from our managers and customers, and certainly nobody said anything about the crap we were giving to our customers and managers—there was only silence. Nobody was talking about careless, helpless programmers. Everything was fine. To paraphrase (and counter) a famous saying by comedian Louis C.K., “Everything was crappy, and nobody cared.”
These were good people. Some were my friends, and they didn’t intend to do any harm. We were doing our best, in the same way ants do their best to vanquish raindrops along their path to the anthill. But we weren’t looking up. We weren’t trying to understand and predict why the rain fell or where it falls from. We didn’t plan better ways to get to the anthill, and we didn’t get better raincoats to protect ourselves from the rain (OK, ant raincoats are a sign this analogy is breaking down, so I’ll stop).
We were all just there, doing our ant-like jobs. Project late? Sure; that’s life. Quality is lousy? Sure; that’s life. Debugging until 3 a.m.? Sure; that’s normal.
Was I the only one reading books? No. There weren’t many trade books, but there were some. But the books my coworkers were reading weren’t getting them anywhere; or if the books had the potential to help them, maybe they couldn’t find the time to finish the books and get there.
There was no sense of craftsmanship. But there was also no sense of professionalism. There were just big downward spirals for every project, as far as the eye could see.
This workplace wasn’t unique, by any means. I encountered many companies like this, with variations, over the years. I hate working at places like that; I always want to make a difference.
This book is about making a difference and getting other people to make a difference as well. It’s the book for those who feel hopelessly trapped in their jobs, even though they’re architects, scrum masters, team leaders, or senior developers. It’s the book I wish I’d had when I first became a team leader.
The book started out as a passionate blog that I kept over several years at 5whys.com (now ElasticLeadership.com). At some point, I collected all the blog posts and published them in a self-published book at leanpub.com titled Notes to a Software Team Leader. When Manning offered to publish it a couple of years later, I jumped at the chance to revise and add content to the book and publish it with the same company that helped publish my first book, The Art of Unit Testing. I’d like to thank Manning for helping me publish this new edition of Notes to a Software Team Leader, now titled Elastic Leadership and with a new format and new and updated content.