Skip to main content

The Problem with Big

Mike Cottmeyer Chief Executive Officer
Reading: The Problem with Big

I mentioned a while ago that Dennis and I were planning to blog our way through this book we are writing. Well, over the holidays I really got serious about writing this thing, and we dropped a pretty detailed chapter outline, and almost 7000 words into draft. The text isn’t finished from a content perspective, or from an editing perspective, but I am going to share some initial thoughts with you guys.

To me, context is so important. There are so many brilliant people in this community, and we all share our ideas from our own particular points of view. Sometimes though, we don’t share the context where we developed those ideas. For me, I have never just worked with a single team. When I got involved seriously in leading agile organizations, I was trying to deal with over a hundred people, 20 plus projects in flight, and had to deliver against a complex systems architecture.
There were no easy answers. None of the books really told me how to do it. We had to figure it all out as we went using the principles to create situationally specific practices. Small team agile doesn’t resonate with me so I tend to write from a big team perspective. That said, I know there are folks out there that don’t share my same set of experiences. So when I sat down with Dennis to hammer out this first chapter, I thought it was important to set context. To give the reader an idea of the kinds of problems we were trying to solve.
God forbid someone take some of these things I talk about here and apply it to a three person team. It would be overkill. To be honest, I am not sure the things I talk about apply if you have 3000 developers either. I suspect they do, but I have never managed anything that large. So… the first few sections of the book are there to help us establish context. Again, this is not polished material, and I am not sure how much it is going to make it into the book. That said, this is how I see the world so I thought I’d share it with you guys.

The Problem with Big

When a company is small, people do what ever it takes to get the job done. There is a sense that you are part of a team and everyone is working toward common goals. Smaller organizations have a strong sense of purpose and a people have direct connection between what they do and the performance of entire organization. There is a camaraderie that comes with having your survival tied directly to your ability to deliver. When this small companies work, success seems to come naturally. People love what they do, they want to come to work, and they are engaged.

This kind of success often leads to growth. Growth often leads to more people joining the team. As our team expands, there are naturally limits to our ability to self-organize (citation). We hire managers and project managers to structure the work. We hire specialists to fill specific gaps in our organizational expertise. We often group our specialists into teams of specialists so we can make best use of their valuable skills and experiences. Teams of specialists end up with their own managers, management hierarchies, career paths, compensation plans and performance incentives.

Over time we end up with functional silos; organization where people are grouped by what they do rather than what they deliver. To deliver an increment of enterprise value, many functions of the organization have to come together to deliver an end-to-end solution. No one functional manager owns the ultimate outcome so we assign accountability to a project manager; the idea being that we need someone who can work across the functional silos. Team members don’t usually report to the Project Manager, the PM is only there to coordinate the work and make sure the business knows what’s going on.

This can be a pretty difficult situation for the project manager, they don’t talk about Projects Managers herding cats for no reason. These Project Managers work with the teams of specialists to break down the work, document all the required activities, provide estimates, develop schedules, get organizational sign-off, and attempt to manage to the plan. Knowing who is doing what all the time becomes a pretty high priority for the PMO. The organization cannot afford to have team members doing any unapproved work. All work ends up being project work and needs to be reflected in a plan.

Because there are so many interdependencies between the teams doing the work, we strive for greater certainty about who is working on what project, for how long, and when they are going to be done. The need for increased certainty results in excessive estimating, excessive task break down, excessive assignment of work and very often, micro-managing behavior. People become overloaded and increasingly separated from the project outcomes. The only thing they can do is focus on their part; the project manager is responsible for making sure everything comes together as planned. Team members become a slave to the tasks on the project schedule. They can no longer help create value.

To make matters worse, specialists are not required full time on every project. To compensate, we time-slice people across several projects to keep them continuously busy. People are in so many project meetings during the regular work day, they have to work nights and weekends to get their real jobs done. If someone does find themselves with extra capacity, that is often license enough to go ahead and start another project. It doesn’t usually matter that there aren’t sufficient resources to get the project finished, the goal is to get started. Starting project that we are not staffed to finish creates dilutes our focus and makes it harder to deliver on our most pressing business priorities.

All of this multi-tasking can lead to a profound lack of teamwork, a profound lack of engagement, and people that focused only on the task at hand; totally disconnected from the value they were hired to create. We end up with a politically charged; do what I tell you or else, corporate culture… a culture that focuses on keeping your head down and staying busy over delivering real results. The solutions to this problem often come in the way of more planning, more project management, more micro-managing activities, more documentation… and of course more sign-off.

Okay… that is the first few paragraphs. Like I said, I’ve got about 7000 words prepped so I post some more over the next few days. Let me know what you think. Does this sound like the places you’ve worked? It sounds like every place I have worked. As always your feedback is most welcome!
Next We Want Our Small Companies Back

Comments (17)

  1. Danny Wahlquist
    Reply

    Yes, Mike, you are right on!

    Reply
  2. Eric Landes
    Reply

    Mike,
    Great context post. I like where you are going, especially on the functional silo part. That really get hairy as the organization gets bigger.

    I hope in the book you will add your ideal "big" organization? Maybe a picture of what that would look like.

    Reply
  3. Mike Cottmeyer
    Reply

    Thanks Danny!

    Reply
  4. Mike Cottmeyer
    Reply

    Not only will we talk about the ideal organization, hopefully we'll explain how to get incrementally get there!

    Reply
  5. agiledreamer
    Reply

    This is familiar. But the perspective is a bit project management centric. Some of the "senior" managers actually feel that they are the ones most accountable, buck stops here etc. And they are often the ones calling for heroics to try to get the project delivered on time or really – delivered not too terribly late.

    On specialists, I think that many people wants to be generalists, they enjoy learning and helping in multiple areas…but somehow the company (the big company) tries to put people into boxes. Tells them, rewards them, encourages them to be specialized.

    I do really enjoy your ideas and writing style… should be quite a fun book to read…

    Reply
  6. Kevin E. Schlabach
    Reply

    Very good… wish I had this before my talk last night since it would have resonated well in the PMI crowd. (Don't worry, I quoted you at least once.)

    Reply
  7. davidburkus
    Reply

    Great point. That's why I love "Small Giants" by Bo Burlingham.

    Reply
  8. andrewfuqua
    Reply

    Three-quarters of the way through I had to look up to see if was reading Mythical Man Month. The style and content sounded like Brooks.

    Yeah, I've seen this before but not in the last few years. That context will help a lot. Without it, I would read your ideas with my more recent small-team point of view.

    Reply
  9. Tokes
    Reply

    You've described the (IMHO) inevitable trends present as companies grow – great job and it totally resonates with my experiences. If you can describe how to effectively deal with these challenges in just as articulate a manner and style then I'll be first in line to get a copy!

    Reply
  10. Mike Cottmeyer
    Reply

    Andrew,

    Thanks for the comment. You know, I am almost embarrassed to say that I have never read that book. After I got your comment, I downloaded it to my Kindle and am working on the 4th essay now. It is one of those must reads that I just hadn't read. The next must read I haven't read is Peopleware.

    Anyway… after just a few essays it is amazing how much of that book has seeped into the collective consciousness. I feel like I have already read it due to exposure to other authors that I have read.

    Thanks for the note!

    Mike

    Reply
  11. Mike Cottmeyer
    Reply

    Tokes,

    We are going to try our best ;-)

    I see this problem in too many organizations. Hopefully Dennis and I can be the guys that help folks fix it.

    Mike

    Reply
  12. Mike Cottmeyer
    Reply

    Thanks agile dreamer,

    You are right about the perspective of upper management feeling like they have actual ownership… because the buck DOES stop with them. I am going to have to acknowledge that in the narrative.

    Mike

    Reply
  13. Mike Cottmeyer
    Reply

    Thanks Kevin!

    Reply
  14. Bob Williams
    Reply

    Nice post Mike. In my planning list for blog posts I have a task to write about organizational entropy. It's based on a lot of the same concepts that you write about in this post. The main thought is that there is a randomness to how to work gets done when resources are assigned (matrixed) to multiple projects. Person A is working on project x and needs person B to help. The problem is person B is working on project y so person A must wait.

    Bob

    Reply
  15. Mike Cottmeyer
    Reply

    Exactly Bob,

    If you haven't read the Boy Scout story in Eli Goldratt's the Goal, it talks about this very problem.

    MIke

    Reply
  16. Nate Schneider
    Reply

    Spot on Mike. I look forward to the rest!

    Reply
  17. Roger Titley
    Reply

    It is not only the concepts of developer and project management that differs in a large organisation. The concept of product owner is also more complex with stories being championed by many individual groups, each with their own constraints and priorities. The product owner becomes more of a product or backlog board.
    The development team is also more diverse with content owners and copywriters, graphic designers, legal, marketing and many other groups being involved each story. The idea of all of these people sitting together in a dedicated and co-located team is naive for a large organisation.
    This doesn't mean that agile cannot be adopted it just requires a more complex and subtle approach and a framework that everyone can relate to.

    Reply

Leave a comment

Your email address will not be published. Required fields are marked *