Notes and Leftovers (in work)
On this page, I’ve assembled a collection of thoughts, leftovers and other interesting tidbits from the writing (and post-writing) of the book. Writing, for me, appears to follow a process that sort of looks like my dad’s old carve-an-elephant joke: “How do you carve an elephant made of marble? You take a block of marble and chisel away everything that doesn’t look like an elephant.”
BTW, if you have enjoyed the book, please do leave a review on Amazon!
Thanks for being part of making better workplaces.
Jack Skeels
(ALSO: I should have this done by the weekend (end of Nov 2023), so thank you for your patience. Lots of moving pieces in writing a book, and I feel bad that I didn’t get this cleaned up sooner.)
INTRODUCTION AND ORIGINS
Trivia:
The stories at the start of the Origins section (Sapient and BLITZ) are the only two pieces of the previous many attempts at this book that have survived, and even these were completely written anew, so as to get the right voice. They are some of the most memorable moments in my life and career, and so I love that readers can witness them as well. Upon reading the BLITZ story (Project on Fire), Brad Atwater, who had been the senior tech lead on that team, wrote to me on LinkedIn that it was an experience that changed his career and his understanding of how to run projects.
Topical Notes
On the Inherent Complexity of Managing
The actual tax (or not) from any given managerial act is driven by the context of that managerial moment, a combination of many factors that can exist in that moment, including:
- The number of managers and their roles
- The direct actions of (other) managers
- The impacts of inaction by managers
- How well-bounded managerial behavior and choices are
- Many decisions in organizational design (because almost any elements of organization structure get “crowned” with a manager), and in their multiplicity in highly managed organizations.
- The type and complexity of the work being managed
- The level of “uncertainty” within the work
- How well-informed everyone is
- What the workers and teams need in order to be most effective
And many more factors. One could argue it is mostly impossible to always get it right, so much time could be spent just figuring out what the situation is before one can even try to act in an effective manager. Here’s an example of the subtlety. (the Stand-up/Check-in new information story follows this)
On Agile
- The working title of that book was How to Run a F**king Agency, by the Guy Whom You Said Could Not Run an Agency. Clearly, I was not unhinged at all.
- 2 Mintzberg, Henry; Managers, not MBAs: a hard look at the soft practice of managing and management development, 2004, Berrett-Koehler Publishers in English – 1st ed.
- 3 The name of our company is a bit of a misnomer as we don’t “do” agile really; nor do we only work with agencies. It sounded catchy, and the domain was available. I tell myself that while there are better names, there are also worse ones.
- 4 The Why Moment also embodies many of the great differences between Japanese and Western management styles and is called Ba, which
(roughly) means “a shared place.” Ikujiro Nonaka, “A Dynamic Theory of Organizational Knowledge Creation,” Organization Science 5, no. 1 (February 1994). - 5 The name agency really means an organization in service of many clients, which is a situation many departments and teams in non-agencies find themselves in these days as organizational silos are broken down by the rapid demands of business.
- 6 My writings on Agile are mostly on Medium.com (https://medium.com/@ jackskeels) but you can also find a more full selection on this book’s online resources page: https://unmanagedbook.com/resources
SECTION 1 – MANAGERS, ORGANIZATIONS, AND METRICS
Trivia:
The stories at the start of the Origins section (Sapient and BLITZ) are the only two pieces of the previous many attempts at this book that have survived, and even these were completely written anew, so as to get the right voice. They are some of the most memorable moments in my life and career, and so I love that readers can witness them as well. Upon reading the BLITZ story (Project on Fire), Brad Atwater, who had been the senior tech lead on that team, wrote to me on LinkedIn that it was an experience that changed his career and his understanding of how to run projects.
Topical Notes
My name is Jack, and I am a Lazy Manager
I am a lazy manager and proud of it. Inc. Magazine even published an article I wrote about it. When I explain it more fully, I hope that you would be proud to be one too. Okay, there is the stigma of the term lazy…but maybe managers shouldn’t take themselves so seriously. Certainly, we’ve seen enough examples in this book (and more) to say that a good portion of managerial actions can be quite counter-productive.
Here’s my story: I got promoted into the role of project manager quite early on in my career. I was a software developer, originally for mainframe software, and I was quite good at it, but I took a role with a factory automation department, and there really wasn’t much out there for factory automation tools, network, etc. My job at the time would now probably fall under the term white hat hacker today, as we were doing things with hardware that were not standard by any means.
I did a few bits of software/hardware magic, and I was offered a project manager job, which was immediately attractive to me. It paid 40% more and I didn’t have to work 60-70 hours a week, which was a bonus, because living in southern California, my life priorities were mainly around going to beach bars and playing volleyball and tennis.
I didn’t like any of the project managers that I knew. I always thought I could do better. So, I took the job, and quite naturally fell into the lazy approach that seemed so much the opposite of the go-go-go, frantic work ethic of my peers.
The way I did it was pretty simple. Every project needed a weekly status report and had its own meeting at some point in the week. I would check in with my teams at the start of the day to see where they were, and deal with anything that they needed. On Thursday morning, at about 10a.m., I would go to the cubicle that Karen, my boss’s admin sat, and I would dictate my project status reports while she typed up drafts for me to edit. I would usually lie down across three chairs when I did this because Wednesday night was “Turtle Race” night at one of the nearby bars, and boy those turtles really could drink.
Projects are prone to have problems, and one of mine was a big facilities project, a buildout in a corner of the assembly plant, installation of 40-foot-long computer-controlled machines and filling in the missing software to get it all to work. The software was the easy part and getting the facility ready for two large machines was not going so well.
For projects that were struggling, I just did a specific “stand-up” meeting for that whole team and had them just run through a list that you will recognize: what got done yesterday, what will we get done today, and are there any blockers I need to take care of. This was 1983. Agile was still 18 years away, but the stand-up meeting has been around millennia.
Otherwise, I simply let the team members do their work. If they had questions, they’d come ask me. It made me realize project managing as a craft was highly overrated. Every project manager I ever knew always acted as if they carried the weight of the entire project on their shoulders, and that regardless of the size of the team, only the project manager could speak about the project. They were its mouthpiece and in many ways its bottleneck.
When someone came to me and asked, “where are we with that project?” I learned to reject the notion of having to be that single mouthpiece. I would reply simply by saying, “Let me go talk to the team.” And then I would go and talk to the team and say, “Hey, team, Ed asked me what’s up and where are we with this?” This gave me the chance to hear what they were talking through and thinking through it.
To me, that was the value of being the project manager. It wasn’t about doing nothing, but it was certainly about actively avoiding doing the things that the team members were capable of doing. They were all capable of thinking, planning, and communicating, and to have some corner-office manager take those things away from them was dehumanizing. I didn’t know of Taylor, but my dad was a very smart, but somewhat quiet and shy man, so in that way, I knew how to take after him.
So, this is where the semantics of the word lazy comes in. To someone who is indoctrinated in the mindset that project management means taking over virtually every aspect of a project and then directing people as to what to do, then I guess I was being lazy. But for someone who believes that 80 percent of project manager’s supposed responsibility is mostly about stuff that other people should actually be doing, and it would allow them to enjoy the project more, I feel my actions were more “efficient” than lazy. I like how provocative “lazy” is though.
It was somewhere during this time that my co-worker and good Turtle Races friend, Bob pointed me at an issue of an IEEE Computing publication that discussed something called IEPM – Iterative Enhanced Project Management. Basically, it suggested that project management should be confined to writing an outline of what the team will work on for the next two weeks, then letting them do that, and then showing it to your customer. You may recognize that as a sprint, though it wasn’t called that at the time.
You probably get that it was a method made for me, the Lazy Manager! I didn’t even really write the 2-week plan, but instead, asked the team and the client to discuss and review what they should do next, and then I would write it up, I mean, have Karen write it up and then I would share it out.
I don’t actually claim that I was a good manager then, and in fact, despite the great success and accolades I received for the work I did in that role, it didn’t make me desire to be a manager at all. But I had stumbled onto something that later in my career suddenly made sense. Serendipity is the intersection of good fortune (often ironic) and the talent to take advantage of it.
A bit more on Andreas
Andreas the master saddle maker knew he was not in the job of making saddles, rather he was in the job of making “saddle-making masters.” The lesson that the apprentice was learning was an equally difficult one for the master himself, many years before. These two people represent two stages in the decades-long progression of the artisanal craft, moving from novice to apprentice, eventually to master, and then to mentor, as knowledge flows and grows across the generations.
Once an apprentice becomes a master, the learning is not finished. In fact, the hardest lesson Andreas ever learned, the one that made him truly a great master and mentor, was that solving other’s problems only makes them weaker. He learned to be patient and to believe in everyone’s desire and ability to learn for themselves.
That is how we used to manage, at least until the Industrial Revolution came along. The master had to be a master of the craft, but also had to be a master of harnessing people’s innate curiosity and problem-solving skills. Helping someone find their own sense of mastery means building a level of competence that will eventually make the student a self-managing expert, capable of creating many more masters. Today we call this coaching, but it resembles much more of what managing should be, as compared to what we often see.
The machines take over the world…but leave the hard parts to us
The industrial revolution never really ended, but the people and the machines have both changed. Machines have become more complex, and at times quite holistic in their scope – as with Tesla’s fully automated assembly lines – and also smarter in many ways. People have become more literate, having greater levels of education and instant access to knowledge. They are more capable than ever, and that’s saying a lot, because they’ve always been pretty amazing.
But the shoe is now on the other foot. As the growth in the industrial economy has shifted to knowledge work. Basic automation is just assumed, but it is the innovations that humans make upon and with that automation that propels business and our world forward. It is knowledge work. And it shifts how one should think about people versus machines.
The shift in economic focus becomes obvious when you ask, “How many computer displays (machines) should a knowledge worker be provided with and how large should they be? “
- Using the industrial-era machine-first, workers-are-the-problem view, where machines are the precious source of productivity, then we would try to hire workers who can work with the lowest cost (smallest) monitors needed. If a worker felt they needed a larger or extra display, this request, when judged from the industrial mindset, would indicate that the worker was in some way defective, “Why do we need to spend more money for a bigger machine so that that worker can just do the same job we pay everyone else for?”
- But when we shift to a human-first view, where workers are the precious source of productivity, then the question becomes, “What sort of machine(s) do we need in order to optimize the productivity of the worker?” [1]
Yes, work today is largely machine-based, but the distinguishing factors are now knowledge worker quality (of course) and whether the machines can “keep up” with the humans, doing the things they need done, enabling them.
The correct, more succinct answer is “How many does he/she need?”. That’s the opposite of the Industrial Era question, “How many workers does the machine need?”
[1] This was studied by Microsoft back in the early 2000’s. It turns out that for many (probably most) classes of knowledge work, multiple displays are in fact a big plus in productivity, their cost is far outweighed by increased quality and output velocity from the worker. In fact, Microsoft found that this productivity boost continued well up to 4-6 displays per worker.
Agile and AgencyAgile
Your ears may have perked up at the mention of “Agile” in my company’s name. Probably best to not get too excited about that – the portfolio of software project management techniques which became known as Agile, which here I will refer to as “Software Agile,” are a mixed bag when applied to most other business situations.
But Agile is a prominent part of business philosophy these days – not only for IT and software people, but for managers and teams too. As such it will likely be something you need to deal with. Much of what you can learn in this book has been inspired by my journey through, and exposure to, Agile techniques, including those that work and those that more often don’t.
When you google the term Agile you will see thousands of articles written about it, what it means, how it should be deployed, and so on. Most of what you’ll read is pretty misguided. How can I make this claim?
Over 200 client organizations so far (we don’t train individuals) and almost every single one of them had tried to implement Agile, and all of them had largely failed. They had hired Agile coaches, read Agile books, done lots of Google searching, but nothing worked. A few years back, at a large software conference, I took an informal survey that found that less than 1 percent of the respondents who had experienced Agile could identify a business benefit to using it. And that was despite the fact they were actually using it.
This vexed me greatly, as I had been using many of the techniques found in Agile since the 1980’s, and the idea that we should somehow change the way we have been doing business in exchange for a model that only sometimes works really well in software projects is, well, kind of crazy. But so goes it with well-marketed management fads, of which Agile is one, for sure.
I’ve written a lot on the topic (the many ways in which Agile is not what it is claimed to be) and rather than make this an Agile book, we’ve placed a nice collection amongst our online resources at:
www.TheArtOf.Management/Book_extras
Included in this collection are topics like:
• How management is killing Agile
• How the Marketing of Agile dooms it to failure
• The many broken forms of “Enterprise Agile”
• The many myths of Software Agile
If you are dealing with one or more Agile initiatives at work, including your department being blown up, or some people telling you that you need to start doing Agile techniques such as Stand-ups, Scrums, Kanban, or Sprints, then please read the appendix to this book: The Many Myths of Software Agile.
If you and I are successful in shifting your managerial mindset, you will be the kind of manager that works well in an Agile setting, and even be able to fix much of the Agile stupidity that is out there today.
If you hold a Software Agile non-team role of some form – often called a Scrum Master or Product owner, or if you are an Agile Coach, then welcome, friend. If you choose to follow what I teach here, you will become much better at your craft, and likely avoid doing Agile-harm like so many of your compatriots have.
If you are one of my AgencyAgile clients, then welcome, also. This is a handbook to how it all works and will de-mystify the many clever techniques that we teach, both Agile and non-Agile, enabling you to understand a deeper perspective around how and why our techniques can work. Basically, managerial nirvana. Safe travels.
So, why is my company called AgencyAgile? I am an entrepreneur, and when I left BLITZ and took on a few more clients using my “techniques” I realized that it sort of looked like Software Agile, and I was, in fact using some modified forms of the same techniques used in Agile. Most of them pre-date the term “Agile” (2001), so while they don’t feel “Agile” to me, they did to my clients. So, since I was helping agencies, I named my consultancy “AgencyAgile.”
Less managing in linked to more productivity.
The amazing successes[1] in the early use of Software Agile demonstrated, as did my Project on Fire story, the potentially massive impact when we decrease the level of managing, effectively un-managing the project.
The solid line in the diagram above shows the loss of productivity that grows within a traditionally managed organization as it and its work become more ad hoc. The dashed line shows how a more neo-artisanal approach to management creates less loss in relative worker productivity.
Organizational ingenuity in all of its forms is at odds with traditional managing; the more you want to have all of those wonderful attributes we listed early in this section, the more you should eschew traditional management techniques because they will hinder them.
[1] As described in The Business Value of Software Agile, productivity boosts of up to 500% were possible using the techniques and management philosophy.
SECTION 2 – UNDERSTANDING AND OPPORTUNITY
Trivia:
The stories at the start of the Origins section (Sapient and BLITZ) are the only two pieces of the previous many attempts at this book that have survived, and even these were completely written anew, so as to get the right voice. They are some of the most memorable moments in my life and career, and so I love that readers can witness them as well. Upon reading the BLITZ story (Project on Fire), Brad Atwater, who had been the senior tech lead on that team, wrote to me on LinkedIn that it was an experience that changed his career and his understanding of how to run projects.
Topical Notes
On Agile
- The working title of that book was How to Run a F**king Agency, by the Guy Whom You Said Could Not Run an Agency. Clearly, I was not unhinged at all.
- 2 Mintzberg, Henry; Managers, not MBAs: a hard look at the soft practice of managing and management development, 2004, Berrett-Koehler Publishers in English – 1st ed.
- 3 The name of our company is a bit of a misnomer as we don’t “do” agile really; nor do we only work with agencies. It sounded catchy, and the domain was available. I tell myself that while there are better names, there are also worse ones.
- 4 The Why Moment also embodies many of the great differences between Japanese and Western management styles and is called Ba, which
(roughly) means “a shared place.” Ikujiro Nonaka, “A Dynamic Theory of Organizational Knowledge Creation,” Organization Science 5, no. 1 (February 1994). - 5 The name agency really means an organization in service of many clients, which is a situation many departments and teams in non-agencies find themselves in these days as organizational silos are broken down by the rapid demands of business.
- 6 My writings on Agile are mostly on Medium.com (https://medium.com/@ jackskeels) but you can also find a more full selection on this book’s online resources page: https://unmanagedbook.com/resources
SECTION 3 – SCOPE AND ALIGNMENT
Trivia:
The stories at the start of the Origins section (Sapient and BLITZ) are the only two pieces of the previous many attempts at this book that have survived, and even these were completely written anew, so as to get the right voice. They are some of the most memorable moments in my life and career, and so I love that readers can witness them as well. Upon reading the BLITZ story (Project on Fire), Brad Atwater, who had been the senior tech lead on that team, wrote to me on LinkedIn that it was an experience that changed his career and his understanding of how to run projects.
Topical Notes
On Agile
- The working title of that book was How to Run a F**king Agency, by the Guy Whom You Said Could Not Run an Agency. Clearly, I was not unhinged at all.
- 2 Mintzberg, Henry; Managers, not MBAs: a hard look at the soft practice of managing and management development, 2004, Berrett-Koehler Publishers in English – 1st ed.
- 3 The name of our company is a bit of a misnomer as we don’t “do” agile really; nor do we only work with agencies. It sounded catchy, and the domain was available. I tell myself that while there are better names, there are also worse ones.
- 4 The Why Moment also embodies many of the great differences between Japanese and Western management styles and is called Ba, which
(roughly) means “a shared place.” Ikujiro Nonaka, “A Dynamic Theory of Organizational Knowledge Creation,” Organization Science 5, no. 1 (February 1994). - 5 The name agency really means an organization in service of many clients, which is a situation many departments and teams in non-agencies find themselves in these days as organizational silos are broken down by the rapid demands of business.
- 6 My writings on Agile are mostly on Medium.com (https://medium.com/@ jackskeels) but you can also find a more full selection on this book’s online resources page: https://unmanagedbook.com/resources
SECTION 4 – PRODUCTIVE FLOW
Trivia:
The stories at the start of the Origins section (Sapient and BLITZ) are the only two pieces of the previous many attempts at this book that have survived, and even these were completely written anew, so as to get the right voice. They are some of the most memorable moments in my life and career, and so I love that readers can witness them as well. Upon reading the BLITZ story (Project on Fire), Brad Atwater, who had been the senior tech lead on that team, wrote to me on LinkedIn that it was an experience that changed his career and his understanding of how to run projects.
Topical Notes
On Agile
- The working title of that book was How to Run a F**king Agency, by the Guy Whom You Said Could Not Run an Agency. Clearly, I was not unhinged at all.
- 2 Mintzberg, Henry; Managers, not MBAs: a hard look at the soft practice of managing and management development, 2004, Berrett-Koehler Publishers in English – 1st ed.
- 3 The name of our company is a bit of a misnomer as we don’t “do” agile really; nor do we only work with agencies. It sounded catchy, and the domain was available. I tell myself that while there are better names, there are also worse ones.
- 4 The Why Moment also embodies many of the great differences between Japanese and Western management styles and is called Ba, which
(roughly) means “a shared place.” Ikujiro Nonaka, “A Dynamic Theory of Organizational Knowledge Creation,” Organization Science 5, no. 1 (February 1994). - 5 The name agency really means an organization in service of many clients, which is a situation many departments and teams in non-agencies find themselves in these days as organizational silos are broken down by the rapid demands of business.
- 6 My writings on Agile are mostly on Medium.com (https://medium.com/@ jackskeels) but you can also find a more full selection on this book’s online resources page: https://unmanagedbook.com/resources
SECTION 5 – LEADERSHIP
Trivia:
The stories at the start of the Origins section (Sapient and BLITZ) are the only two pieces of the previous many attempts at this book that have survived, and even these were completely written anew, so as to get the right voice. They are some of the most memorable moments in my life and career, and so I love that readers can witness them as well. Upon reading the BLITZ story (Project on Fire), Brad Atwater, who had been the senior tech lead on that team, wrote to me on LinkedIn that it was an experience that changed his career and his understanding of how to run projects.
Topical Notes
On Agile
- The working title of that book was How to Run a F**king Agency, by the Guy Whom You Said Could Not Run an Agency. Clearly, I was not unhinged at all.
- 2 Mintzberg, Henry; Managers, not MBAs: a hard look at the soft practice of managing and management development, 2004, Berrett-Koehler Publishers in English – 1st ed.
- 3 The name of our company is a bit of a misnomer as we don’t “do” agile really; nor do we only work with agencies. It sounded catchy, and the domain was available. I tell myself that while there are better names, there are also worse ones.
- 4 The Why Moment also embodies many of the great differences between Japanese and Western management styles and is called Ba, which
(roughly) means “a shared place.” Ikujiro Nonaka, “A Dynamic Theory of Organizational Knowledge Creation,” Organization Science 5, no. 1 (February 1994). - 5 The name agency really means an organization in service of many clients, which is a situation many departments and teams in non-agencies find themselves in these days as organizational silos are broken down by the rapid demands of business.
- 6 My writings on Agile are mostly on Medium.com (https://medium.com/@ jackskeels) but you can also find a more full selection on this book’s online resources page: https://unmanagedbook.com/resources
SECTION 6 – THE INGENIOUS MANAGER
Trivia:
The stories at the start of the Origins section (Sapient and BLITZ) are the only two pieces of the previous many attempts at this book that have survived, and even these were completely written anew, so as to get the right voice. They are some of the most memorable moments in my life and career, and so I love that readers can witness them as well. Upon reading the BLITZ story (Project on Fire), Brad Atwater, who had been the senior tech lead on that team, wrote to me on LinkedIn that it was an experience that changed his career and his understanding of how to run projects.
Topical Notes
On Agile
- The working title of that book was How to Run a F**king Agency, by the Guy Whom You Said Could Not Run an Agency. Clearly, I was not unhinged at all.
- 2 Mintzberg, Henry; Managers, not MBAs: a hard look at the soft practice of managing and management development, 2004, Berrett-Koehler Publishers in English – 1st ed.
- 3 The name of our company is a bit of a misnomer as we don’t “do” agile really; nor do we only work with agencies. It sounded catchy, and the domain was available. I tell myself that while there are better names, there are also worse ones.
- 4 The Why Moment also embodies many of the great differences between Japanese and Western management styles and is called Ba, which
(roughly) means “a shared place.” Ikujiro Nonaka, “A Dynamic Theory of Organizational Knowledge Creation,” Organization Science 5, no. 1 (February 1994). - 5 The name agency really means an organization in service of many clients, which is a situation many departments and teams in non-agencies find themselves in these days as organizational silos are broken down by the rapid demands of business.
- 6 My writings on Agile are mostly on Medium.com (https://medium.com/@ jackskeels) but you can also find a more full selection on this book’s online resources page: https://unmanagedbook.com/resources
Who should read this book
- Leaders of organizations:
- You will be inspired to unlock the unmanaged potential within your organization. You will gain a mastery of the Why Moments, which will make you a better, more-inspiring leader.
- Managers:
- This book should be your handbook. Prepare to be delighted by an almost annoyingly comprehensive collection of information about what we do wrong as managers, and what we can do better, much better.
- Workers and team members:
- In many ways, this will probably validate experiences that you’ve had with managers, some of which might become more comprehensible as a result. Hopefully, the knowledge here brings you some power in that way.
- AgencyAgile clients and alumni:
- Here are the underlying big idea, a handbook to accompany our trainings. A reminder, and hopefully a few laughs for you, from the stories, vignettes, and models that we have shared with you over the years. This book should remind you of the why behind many of our techniques and methods.
- Those in “Agile” workplaces:
- This book will help you decode some of the ideas in the original Software Agile, and even guide your organization away from the rocky shoals of Agile upon which many a change initiative has been wrecked.
