We’ve been ‘incubating’ projects over on the Mach 30 Drawing Board because honestly, there are waaay too many good ideas out there and too few of us on the Mach 30 board. One of these ideas, the Book Club, was recently brought to life during a weekly hangout.
The group decided that they wanted to kick off this new project by reading the book X-teams: how to build teams that lead, innovate and succeed. So here we go! There’s a ton of great background on the drawing board page for the Mach 30 Book Club idea. I’d suggest taking a quick glance through that so you know what to expect.
X-teams: How to build teams that lead, innovate, and succeed
We’ll start by discussing the Introduction to the book on Monday, November 26th. If you want to be part of the discussion you can add comments to this blog post, even if you don’t have an account. If you click in the “Leave a Reply” box below you’ll see options to post as your Twitter and Facebook logins too. We’re really looking forward to getting started with this book, and we hope you’ll join us. If you’re a part of teams in any way, this will be a great discussion.
So, grab a copy of the book, a comfy chair, a hot or cold beverage of your choice, and lets get started!
I started reading this book a little over a year ago but got distracted before I was able to finish it. I’m excited to finally go through and discuss as I go, this time.
Just nabbed the e-copy of the book. Looks very interesting! This is a great topic and a great idea.
======= DISCUSSION THREADS: ==========
As we get into the meat of the book, the conversation may flow a little more organically. But until then, here’s a few tidbits to get the conversation flowing. If you want to participate, take a look and respond to the following prompts:
============ Introduction: ==============
– In your own words, summarize the Introducation in 1 sentence.
– After reading the introduction, what do you hope to get out of the rest of the book?
Hope to hear from you! The more participants we get, the better the discussions can be, so please contribute. At the end of the week, we’ll announce the reading assignment/questions for Chapter 1.
Long time reader, first time poster…
The introduction just serves to portray the importance of WHY a project is being done (to fulfill a need or take advantage of an opportunity) and continuously evaluating if it is still the best solution based on changing conditions is as important as HOW it is being done.
Reading the introduction, I think it is important to keep a wide perspective on the ideas presented. Being internally focused does occur in teams, but it also happens in schools, organizations, communities and even entire countries. Many companies quickly lose their footing when they start focusing too much on internal initiatives without asking themselves how it will benefit customers. I also believe the content will reaffirm agile programming and design methodologies, which incorporate constant feedback and functional maneuvering to ensure that as conditions change, the solution evolves to best fit the needs. I look forward to gaining a balanced perspective regarding project management and leadership!
Thanks for doing the book club – should be very interesting!
All good points Mark. The connection to design methodologies is an interesting one that I too would expect to be affirmed as the book goes on.
It’s easier/safer in many ways to stay within our internal boundaries because “out there” is an unknown set of conditions that we may not be able to control or easily understand. Things can get messy when you start pull external input into your project, but there’s no other choice. If you want to be able to adapt to survive, you have to be able to gather the information to know how to adapt.
On the subject of keeping a wide perspective, I thought it was interesting that the authors mentioned effective team building as a way to help solve problems like poverty, global warming, and political violence. The political issues involved with these problems is much more complex than anything you’ll see in a corporation, and I have a hard time even imagining how you would set up X-teams joining governments, businesses, NGOs and the like. I’m kind of hoping the authors will give additional thoughts on this later in the book.
Howdy Mark,
Thanks for your participation and welcome to the book club discussion! That’s a great comment about hos an external perspective can be important to more than just product design teams. I’m looking forward to hearing your thoughts and perspectives on the rest of the book!
Q1: “In your own words, summarize the Introducation in 1 sentence.”
A1: An effective and innovative team needs to balance internal and external focus through distributed leadership, adaptability an flexibility.
Q2: “After reading the introduction, what do you hope to get out of the rest of the book?”
A2:
Since I’m a Mach 30 volunteer and a business owner, I’m interested in X-teams from a couple of different perspectives:
1. From the Mach 30 perspective, I look forward to seeing how X-teams can be applied to our hardware development teams since our development model is very distributed in nature. I’m hoping that X-teams will give us a great way to organize and unite everyone interested in helping Mach 30 build the future of spaceflight. Also, sustainable leadership is one of the three main principles that Mach 30 is built on, and I’m assuming that X-teams can help us in this area as well.
2. From my perspective as a consultant, I’m always looking to for ways to more effectively interface with the corporate teams that I come in contact with. In addition, I feel that being a consultant/contractor is not just popping in, doing the job, grabbing the check, and then leaving. It’s about adding value to the company as a whole when possible, and I’m hoping that X-teams will be another tool that I can use to add that value.
Ok, here’s what I came up with…
Q1.) 1-SENTANCE SUMMARY: Every team can benefit from focusing on both the internal group dynamics and the external environment in which the team operates, but in fact, managing the external environment and adapting the team to the changing external conditions are the best ways to ultimately lead to more highly performing and successful teams.
Q2.) I HOPE TO GET OUT OF THE BOOK: When we’re done, I intend to be able to clearly describe, in my own words, the concepts of what makes an X-team, and the importance of these ideas to any modern, (information age) organization. Secondarily, I’d like to identify the areas where Mach 30 is already operating like an X-team and quantify how this is working for us. Then evaluate the remaining areas where the X-teams principles apply (and conversely, where they do not apply) to allow us to refine our Mach 30 processes to more intentionally implement these techniques in a manner that is transparent to everyone. *Phew* that’s a mouthful.
Ok Jeremy, I guess that’s it (just you and me) for the Introduction. If anyone else has additional comments on previous posts, you can reply directly to them above. For those who are following along and haven’t made any comments, yet, please feel free to join in at ANY point in the conversation. The Mach 30 book club is meant to be very informal. We hope to have you join us in later discussions!
This will wrap up the first week’s discussion. I’ll post the starter questions for Chapter 1 next.
======= DISCUSSION THREADS: ==========
I’m announcing that we will be discussing the next section starting Monday, 3 Dec 2012. Please read Chapter 1 of Part 1: “Into a downward spiral: How our old models lead to failure.” As you’re reading, here are some questions to consider.
============ Chapter 1: ==============
– Can you share a personal example, or another example not in the book, of a team failure (or a success) that was due to the team’s inward focus?
– Using chapter 1 as a starting point, develop a list of “inwardly focused” keys to team success. The point is to summarize the “old models” to which the authors refer.
I’m having a hard time coming up with a good/interesting personal example, but what Mark said above about having a wide perspective got me thinking. At least in the state where I live, there are a lot of small towns jumping on the industrial park bandwagon. The thinking seems to be “build it and they will come”. From my perspective though, many of these towns are not focusing externally enough (or maybe not at all) before taking this plunge. Instead of finding out what their target clientele wants, they assume that the vanilla phone, internet (maybe), office space combo is going to draw people in. Some don’t even go that far, and just put up an “Industrial Park” sign on a seemingly appropriate structure. As a result, far too many of these facilities sit empty or are vastly underutilized. It will be interesting to watch many of the spaceports that are popping up around the U.S. in this respect. So far they seem to be doing a good job of targeting what their audience needs, but I wonder how much of this is due to external focus and how much is do to the fact that many of them reuse decommissioned government facilities and thus have a head start. I really don’t know, and I’m hoping that there’s enough external focus and adaptability to make them viable long-term.
In regards to the second question (I hope I’m understanding it right):
Keys to success with a heavy internal focus:
1. The team has all the information it needs within its boundaries.
2. The team does not have to work with other groups within the organization.
3. The team’s task is clearly defined and unchanging.
4. There is already support and buy-in within the organization for the team’s project.
The first 3 items are almost never a part of projects I’m involved in.
1. There’s always additional information that you have to go to outside sources for, and new developments are always popping up.
2. Not since my days as a young intern have I not had to work with other groups to get projects done.
3. The task is often clearly defined, but things never fail to change over time, especially with long term projects.
One of my first large projects was to do a rewrite of an old DOS program for the then relatively new Windows environment. I was working with the engineer that designed the DOS program, and he knew everything that it did inside and out. We worked well together, and using his experience, wrote the new software. The problem was we didn’t do enough (any!) mock ups to get user input into what we were designing. We didn’t visit customers to get a first hand look at how they were using the existing software and what they would like to see in the next version. We did get some feedback from our sales team and trainer, but is was based on their assumptions and not true end-user experience. We plowed right into the code, without considering things like how a user in a factory would like using a mouse, or how many machine operators would even relate to the Windows-style interface. We wrote another one of those obviously engineer-designed interfaces that you see in plants everywhere that focused more on the machine operation (we were the machine manufacturer) than the operator’s needs and skill level. We didn’t do much operator-level usability testing, or have a designer assist with the layout. Once in the field, we often had to teach the operators Windows and how to use the mouse. Being new to the industry, I simply assumed people would be familiar with the new interface paradigm and it would be simpler and take the market by storm. The product provided a lot of sales revenue, but also caused a lot of support calls and service visits to assist with the new system. We missed the opportunity to create a revolutionary product and instead created an evolutionary product that for some was much more difficult to use. Needless to say, if I knew then what I know now, we would have approached the project much differently by visiting potential customers first and involving them in the design process from the start.
An inwardly focused team is going to concentrate on team dynamics, project definition, schedule, team member training, and be able to easily report on progress at any given time. These things are much easier when the project is cast and the team can focus on the well-defined end result that doesn’t waver.
One of the many things that I’ve always liked about the Unix/Linux philosophy (and FOSS in general), is the focus on getting prototypes into users’ hands early on. The “prototype early, prototype often” methodology can be seen with most open source projects. I’m trying out FreeCAD, which is currently in alpha, and the developers warn that it’s “not ready for production use”. Even so, putting it out there early allows the developers to receive feedback on what features users actually use, and what they want in an open source 3D CAD package. That’s not even taking into account the bug reports that you get from users. It also gets the ball rolling on financial donations and new volunteers to help make the project more successful in the long run.
However, just because a developer gets feedback doesn’t mean they’ll be overly concerned about what their users want. Some will only develop the features they want/need, and users have to take what they can get.
I haven’t had a chance to pick up the book–(bad board member!) but the conversation about the importance of looking outside the organization and how to do that reminded me of the “Core Purpose” section of this article. Thought another perspective on a similar concept might be useful http://air.rocket-dev.com/img/site_specific/uploads/knowledge_items/53/Building_a_Vision.pdf
Howdy Maureen,
Thanks for your participation, in spite of the not reading bit. …and I hope you’ll continue to contribute! B-)
I think that the author’s underlying theme is that there is a need for both internal AND external focus in teams, and that most teams focus primarily on the internal work.
It also seemed to be a (relatively) tacit assumption that in order for X-teams to be at their peak effectiveness, all the internal (sometimes called “touchy-feely”) work needs to be well established. For example, it will be much easier to engage with the external world when the foundation of the team is solid. I consider the team foundation to include things like: interpersonal team dynamics; decision making process; solidified mission, vision, and values statements which all leads to a clear core purpose. I think we’ve done this very well at Mach 30, and should be proud about that.
======= DISCUSSION THREADS: ==========
It’s Monday, 10 Dec 2012, so that means we’re covering Chapter 2 – “A Changing World” As you’re reading, here are some questions to consider. Feel free to answer some or all, and also to use them as inspiration to ask your own questions.
============ Chapter 2: ==============
Q1. Due to the way X-teams work, there is a shift of some executive level responsibilities and tasks to the team level. In at least one place in the chapter, the authors mention that this has lead to an increased workload on the team members. How do you feel this might affect the long-term quality of life and morale of these teams, if there is even any effect?
Q2. On page 53, the authors mention that “teams cannot afford to reinvent the wheel”. This seems to be a very Open Source-like statement. Do you see any connections in what you’ve read so far between X-teams and the Open Source movement?
Q3. What main factors do you feel have lead to scientific and technical knowledge becoming more complex and advanced, leading to that knowledge becoming more dispersed. In other words, why can’t you find all the knowledge you need within a large organization like GE as you could in say, 1960.
Q3a. Do you think this increase in the complexity and dispersion of knowledge will continue to accelerate as time goes on?
I wanted to address at least the first question. I may get back into the full discussion thread in-around the holiday vacation.
Question/Answer1: Yes, there is an increased workload at the team members level. There is also a higher work level for folks that work entrepreneurial and start-up companies too. You have to have a certain personality and skill set in order to thrive in that type of environment. Not everyone is cut out to work on an X-team, just like not everyone is cut out to be an entrepreneur or start-up business owner. I think that the “burn out” happens when team members who are not willing or able to meet the increased demand of X-team participation leave the team. I wouldn’t necessarily call that burn out as much as organically shaping the team with members who can work well in this new way.
@Greg – Good points. The difference that I see is that in entrepreneurs, there is normally an expectation that working long hours and enduring higher stress levels in the short term will pay off in the long run. With the entrepreneurs that I’ve talked to over the years this almost always involves making a higher salary than they can working for someone else. There’s usually the drive for freedom and independence too. Will having the work/stress load increased be acceptable for most entrepreneurial minded X-team members when they know (or at least perceive) that it will lead to relatively small pay increases and independence?
Your point about “organically shaping the team” is well made. As long as the organic shaping doesn’t take the form of needless high turnover, it may just be part of what makes an X-team work.
Pingback: Mach 30 – It’s Not Just for Engineers « Mach 30
Howdy All, and Merry Christmas too! I’m going to put the Book club on hold over the Christmas holidays. I’m behind in my reading and moderating questions so, lets start back up again after the New Year. I’ll post the starter questions for chapter 3 on January 5-6, 2013.
Until then, wishing everyone a happy holidays; and may your upcoming year be filled with peace, magic, and dreams. B-)
Happy New Year everyone! It’s 2013 and time to pick up where we left off with the Mach 30 Book Club reading the book X-teams. Thank you to all who have commented already. I know that there are others reading along, and I encourage you now to comment, even if it’s not about the teaser questions for the chapter or even about the current chapter at all! We want to hear from you.
======= DISCUSSION THREADS: ==========
Starting Monday, 07 Jan 2013, we will just be getting into Part 2, “What works.” Chapter 3 is about the first principle of X-teams, namely External Activity.
=========== Chapter 3: ==============
– What, if any, parallels can you draw between “vicarious learning” (page 72) and the open source methodology?
– How does the team’s leadership affect the ability to engage externally? In a “flat” or “leaderless” organization, how can External Activity be encouraged without a formal leader?
– Do you have examples of how external activity (scouting, ambassadorship, and task coordination) have been applied, either successfully or unsuccessfully?
Well I may just be talking to myself on here, but for my benefit, and that of others reading along, I’ll answer my own questions. These answers may get rather lengthy, so I’m going to break them up into 3 replies… OK, here’goes.
Q1-VICARIOUS LEARNING AND OPEN SOURCE:
(note: this answer is written by a complete open source (OS) noob, so my understanding may be skewed, or flat out wrong. Any clarifications would be welcome).
It’s apparent to me that the open source (OS) developers tend to be very big into vicarious and self-learning. However I see a distinction between the process of teaching yourself what you need to know for contributing to OS projects, and the “vicarious learning” principle of X-teams. In the OS community, individuals must continuously update their skills to be a part of the coolest new projects. This is most obvious in the OS software examples that I’ve witnessed. I’m less clear about learning in the OS hardware community for 2 reasons. First, it’s very new. And second, I’m not sure that there is a lot of cross-pollination of OS hardware contributors (yet). Now, I see the main difference between this personal education and the “vicarious learning” principle is the X-teams emphasis on the learning of the team at large. In the “vicarious learning” examples, team members go out and educate themselves, and in turn educate the team, on principles that may be outside of the team’s scope or industry. My favorite example is the design firm IDEO who ran a project to improve Operating Rooms by studying NASCAR pit crews. Their work involved more than just improving medical/surgical proficiency, and instead focused on incorporating the concepts and ideas from a completely different industry that applied to a surgical team.
I’m going to mix a little bit of comparison with things that I think the open source and open hardware movements can take away from the concept of vicarious learning. I was going to answer the question more directly, but my mind took this direction instead.
1. Copying or modifying what other teams have already done. I see a lot more of the copying of open hardware and open source software than of anything else, which is fine and good, but not the entirety of what chapter was talking about in my mind. In the chapter it’s more about the how than the what, meaning that you learn how another team did something so you learn how to avoid pitfalls, and gain hard won insights. You don’t have to repeat the other team’s failures. That’s one reason Mach 30 documents our entire engineering process, from the initial assumptions and goals we start with all the way through to the errata (problems with the design).
Unfortunately though, it’s been my experience that many open source groups are so eager to get started and forge their own path that they don’t always take the time to thoroughly research what’s already out there. It’s great to forge ahead and be on the cutting edge, but you don’t want to reinvent the wheel along the way. If you stand on someone else’s shoulders you’ll be able to reach much higher much more quickly. To me, this is what the FSF’s software freedom #3 is about – continually building off of each other’s efforts to accelerate development. http://www.gnu.org/philosophy/free-sw.html
2. Getting information from unexpected sources. In the chapter, teams in one industry would find and learn from teams in another industry. The outside team had already gone through the process the X-team was now in the midst of. I think that this highlights that you shouldn’t wall yourself off to learning from another, very different, open source project. If you’re working on a rocket motor test stand, you shouldn’t be opposed to learning lessons from a team that is working on an E-textile project. You’ll see this in action on forums, Google+ groups, etc where there is a good diversity in the participants.
3. Being on the lookout for technologies that were dropped but are still viable. The chapter mentions that the RAZR team picked up on technologies that were dropped for various reasons. These technologies were abandoned, but still had the potential to be reused or re-purposed to make the RAZR team’s product a reality. However, I think there’s a balance here between learning from other teams about what technology didn’t work, and being willing to revisit an abandoned technology. It would probably be best to check with another team on why a piece of technology didn’t work for their project before evaluating whether or not it will work for yours.
Well I may just be talking to myself on here, but for my benefit, and that of others reading along, I’ll answer my own questions. These answers may get rather lengthy, so I’m going to break them up into 3 replies… (part 2 of 3):
Q2-LEADERSHIP EFFECTS ON XTEAMS: It seems like a “normal” team can be transformed into an X-team given the right leadership. If the leader is clear about the need for external engagement, as an example, then the rest of the team can follow. However, in “flat” or distributed leadership teams, it seems like it may be much more difficult to mandate the activities of an X-team. These teams are already working “outside of the box” and it seems like all the “normal” team processes and dynamics go out the window. Implementing a new X-team process is a bigger challenge because all members of the team need to be informed about what that even means.
Well I may just be talking to myself on here, but for my benefit, and that of others reading along, I’ll answer my own questions. These answers may get rather lengthy, so I’m going to break them up into 3 replies… (last question):
[I’m going to use Mach 30 as an example, and I have comments for each X-teams sub-principle. Additional comments will be added later after I finish editing my response.]
Some may have noticed another lull in the Mach 30 book club posts. I’m recovering from a flooding emergency at my house, so I’ve had no time for any reading. If you’re keeping up with the readings, please comment! Thanks.
Thanks for the update Greg.
Pingback: Exploratory Learning | Mach 30