There’s a fundamental pyschology concept called “Bystander Effect“, where a group of people are less likely to help someone in need than when a single person is present. Everyone in the group thinks someone else will/should help the victim, instead of them.
Think about this when you send an email — I recommend you clearly articulate who you want to do what, and ideally only put 1 person in the To: line of the email (even if you have a few people in the CC: line).
While it’s a gross oversimplification to say that I draw (I use the term “draw” loosely) on a whiteboard for a living, it’s amazing to reflect on how much of my time is spent using a whiteboard for all kinds of things (most of which are incredibly valuable to the work I’m doing). I can tell I’m spending a majority of my time on the whiteboard while at work, because my smartphone pictures are about 25% whiteboard pictures and 75% pictures of my adorable son (and beautiful wife).
As a Chief Technology Officer, I end up using the whiteboard for all kinds of things, like:
- Facilitating solution architecture discussions and development with subject matter experts (technical experts) and people who understand the needs of our customers, creating things like Concepts of Operation (ConOps), system architectures, and unifying proposal roadmap figures
- Outline and storyboarding proposals before we start digging into these (This is key — just like software engineering, you need a plan/architecture before anyone writes any code)
- Creating product backlogs and release plans, where I sometimes throw in some painter’s tape and sticky notes so I don’t have to keep rewriting the user stories when I move them between releases/sprints
- Creating user interface wireframes (whiteboards are great for this, because they force you to focus on the big picture — just like using a Sharpie to sketch these on paper, instead of a pen)
- Creating process map and flowcharts with process owners, trying to define current and to-be business processes (and sometimes trying to map the value of different steps while refining)
- Sketching out tables to validate content structure before going off to create them in a tool like Microsoft Office or Confluence
That said, I want to be clear that the pictures of my wife and son are much cuter than my whiteboard pictures.
Capability Maturity Model Integration (CMMI) is a process maturity model focused on helping organizations mature how they create things (CMMI for Development), provide
services (CMMI for Services), or buy things (CMMI for Acquisition). The predecessor to CMMI, CMM, was created back in the late 80’s and early 90’s due, in part, to systemic issues with software development in support of Department of Defense projects.
CMMI often gets a bad wrap for being a bureaucratic, paperwork-heavy set of compliance checklists that doesn’t help anyone and is really annoying. While it certainly can be, if you focus on using it to make your processes better (and not just check the boxes to get a rating) it can be a great way to mature how a company operates. I’ve been really impressed with how powerful it can be, especially for small technology companies where processes are not formalized, and project teams depend on heroes from each team, with prior training and experience to ensure project success.
CMMI can be a very valuable investment, that transforms a company into one that has projects that are more predictable and lower risk, and an organization that is continually improving; but the investment isn’t small (think on the order of $100K). Some of the big cost areas are:
- Sending people to take classes in CMMI
- Allocating people’s time toward planning, creating, and training process development and improvement
- Bringing in consultants to coach and support process improvement
- Bringing in a Lead Appraiser to formally assess an organization for compliance to CMMI
If you’re interested in pursuing CMMI for your organization, I’d caution you that it’s a big undertaking, and you shouldn’t pursue if it you’re just doing it to try to be impressive to potential clients or get the ability to bid on work that requires CMMI. If you don’t buy into the idea of investing time and money into making processes better, you’re going to spend lots of money making everyone’s life worse at your company
If you are excited about making that investment in how your organization runs (very much working on your business instead of in your business, see E-Myth Revisited), make sure you take your time in selecting people to support your pursuit who are great at what they do and bought in to how you do business. If you’re a big Agile development shop, don’t work with someone who has “taken an Agile class or two” — you want to work with people who really know your business model and business perspective well.
- Take the 3 day Introduction to CMMI from a great teacher — someone like Bill Smith, who makes CMMI interesting and engaging
- Go to a CMMI conference (SEPG) if you can — this is a pretty small community, so it’s a very accessible community to go to one conference and get to chat with the thought leaders and meet companies like yours
- Get a hardcopy of the CMMI book for the constellation you want to pursue (e.g. CMMI for Development) and actually read through some of it. It’s a big intimidating book, but the introductory content and the overviews of each of the practice areas is pretty accessible. You’ll want to keep a copy of this and mark it up as you learn more about it and how it relates to your business.
- If you get consulting support (which is critical, unless you have a CMMI pro on your team), shop around and really interview them well to understand their style, areas of expertise, and level of experience — I’ve been really impressed with consulting from thought leaders like Broadsword, who know the Agile-CMMI intersection very well (and their senior leaders, such as Jeff and Ross put out great blog and webinar content), and great appraisers like Frank Koch who really help companies understand what CMMI really means for a company like theirs
- Don’t try to “do CMMI” in a vacuum from other parts of your organization — any other process improvement activities, such as ISO 9001, back-office process development, or overall organizational process architecture should be integrated (or you’ll have to spend more energy integrating them later)
- Don’t over-engineer — it’s important to avoid letting technical people create too much process instead of focusing on the most valuable process improvement work
- Ask questions — the CMMI community is full of people who want to help people make their companies better
A few years ago, we did a team building exercise at work which involved the group collaborating on a vague project with no defined roles for any of us. I think exercise was intended to show how different personality types could better collaborate, though I learned a very different lesson.
The group of about 15 people was given a vague task, and no leadership roles were assigned. After what felt like roughly eternity happened, I jumped up to the whiteboard to start facilitating a discussion on how to tackle the challenge. At the end of the exercise, the person leading the exercise asked me how long I felt like I waited before getting up. I estimated something like 30 seconds. I was quickly corrected that it was more like 3 seconds. In the awkward (at least to me) silence of no one leading or coordinating, I jumped in to coordinate. I regret not being more self-aware — I wish I could have let people who weren’t in leadership roles get to practice leading and facilitating.
My father, a career 6th grade school-teacher, always talked about the concept of Wait Time when I was growing up:
It can be extremely awkward when a teacher asks the class a question, and it’s met with nothing but crickets. Research has shown that in most classrooms, students are typically given less than one second to respond to a question, regardless of grade level. At the end of that second, some teachers break the silence by either expanding the question or providing the answer. Other teachers choose to cold call on a student for an answer, which typically results in a brief recall response or an embarrassed shrug.
This time period between the teacher’s question and the student response is called wait time…
The teaching concept of Wait Time talks about the need to allow enough time for people to think about a question and formulate an answer. The concept of wait time should be applied both to letting someone answer and also ensuring that you don’t respond immediately, without thinking about what they said.
Brian Regan (a hilarious comedian) captured it well in his Me Monster bit, where people are trying to one-up each other, waiting for the other person’s lips to stop moving, so they can tell their story to impress everyone else.
Nobody likes the Me Monster, and nobody likes the person who can’t wait for a few seconds to hear what other people in the group think.
In my recent focus on internal IT infrastructure and process (more CIO and less CTO), I’ve been searching for relevant CIO resources — here are a few I’ve found useful.
It’s very easy to get caught in a constant posture of reaction, where you are constantly putting out fires instead of actually improving teams/systems/processes. I was listening to a 22 Feb 2012 podcast from Michael Ellsberg (https://itunes.apple.com/us/podcast/the-michael-ellsberg-show/id673996932) recently, where he interviews Bryan Franklin; and I was struck by one of the comments Bryan made: He talked about how great leaders don’t “exhale” (relax) when the specific issue is resolved; instead they relax when they have put a system in place that prevents that type of issue from happening again. This idea of building systems is something many talk about; but it’s something that’s very difficult to prioritize above daily, tactical things.
This concept reminds me of so many related concepts such as:
This yields value as you continue to build systems in your life.
I just finished reading Michael Holley’s War Room: The Legacy of Bill Belichick and the Art of Building the Perfect Team and Reed Hastings’ 2009 presentation on Netflix’s culture. Both are full of great ideas on leadership, and as I read them I was struck by how delicate the balance is between creating a culture that focuses on following processes and a culture based on giving employees significant discretion. Holley’s book described a Patriots team that provides discretion framed by a comprehensive, complex set of recruiting (draft) and management systems, while Netflix’s culture slides emphasize an approach that could be described as “hire great people and get out of their way.” It’s interesting to see how different organizations balance these
two approaches as they grow. Netflix describes this challenge and their approach very well in slides 46-58 (it’s worth clicking on the link and skipping to slide 46 if you don’t have time to read them all). They focus on getting higher quality talent to manage the business as they grow, instead of becoming more process-based.
This is more of a question of attracting Theory X employees vs. Theory Y employees. It’s a question of can Netflix (or other companies) really accomplish the mission of growing a company of autonomous, talented people using a decentralized management structure indefinitely? Or is there a company size in which this breaks down due to either management complexity or the ability for a company to attract sufficient high-quality talent?