I constantly forget where I bury my nuts, but at least they sometimes grow trees.
Dispelling Mythical Holacracy
Journalists and bloggers have sensationalized Holacracy in the past couple months with headlines like “How Zappos is getting rid of managers to retain a flat startup culture”. In the process, they’ve spread a lot of misinformation, and a lot of people now mistakenly believe that Holacracy is way to flatten a company into a non-hierarchical, leaderless, ambiguous collective.
A few quick examples…
"In November at the [Zappos] all hands meeting, [Tony Hsieh] announced that the 1,500-employee company would be restructuring into what is known as a ‘Holacracy’. That means a flat structure, with no job titles and no managers." — Christina Farr, Venture Beat
"The absence of structure is a structure in and of itself. When you allow a power vacuum to emerge someone will fill it, and it’s usually the people who have traditionally held power (rich white men). That’s how you end up with stories like this coming out of GitHub." — Catherine Bracy, Code for America
"Holacracy is about flatness. Think hierarchy and then think the opposite for holacracy." — William Tincup, fistful of talent
Dev Bootcamp adopted Holacracy last October. We’ve been using it as our organization’s operating system for 6 months now. I’d like to share some of what I’ve learned about Holacracy, starting with the aspects of Holacracy that clearly contradict the dominant narrative floating around about it.
Holacracy is inherently and explicitly hierarchical. There is a Board, whose leader (aka Lead Link) appoints the leader of the company. The company leader appoints all leaders of the next layer of leadership. Those leaders can appoint any leaders of sub-divisions (aka Circles) under them. We use software called Glassfrog to work with Holacracy. The default page in Glassfrog provides a nice visual representation of our hierarchy.
Holacracy has job titles (aka Role names). The most significant difference between typical job titles and Holacratic roles is that a job title typically corresponds to a 40 hour/week set of responsibilities, whereas Holacratic roles are typically much more fine-grained. For instance, one of my co-workers energizes 17 different roles, such as Event Staffer, Local Onboarding, and Office Manager. Since roles can be fluid, we did get rid of our former titles and replaced all of them with a simple and consistent “Partner” title. And yet, each of us tends to identify with one primary title. I used to call myself the Director of Chicago, and now I call myself the Lead Link of Chicago. Teachers still call themselves Teachers.
Holacracy’s power structure is explicit and clearly visible to the whole company. As I already showed you, Holacracy has a very explicit power structure. It’s a hierarchy, but Holacracy adds something special to it. For every divisinon head, aka Lead Link of a Circle, there’s a corresponding representative elected by the Circle. This person is the Rep Link, and this role’s purpose is to raise any unresolved tensions up the hierarchy to the parent Circle. This role provides a balancing effect against any domineering Lead Links. Rep Links operate in the parent Circle, just like Lead Links, with the same authority to propose, reject, and process governance.
Holacracy lets you refactor your organization. Software development has a term called refactoring. It means to improve the internal design of your code without changing its behavior. About 3 months into working with Holacracy, we started applying principles of Object-Oriented design to our organization, such as Don’t Repeat Yourself and Single Responsibility Principle. Unleashing our programmer brains on the structure of the company and the roles that we work in every day has resulted in far greater clarity of our roles, responsbilities, and authority (aka Domain).
Holacracy is autocratic. When a role has the authority (aka Domain) to make a decision, the person in the role doesn’t need to consult with anyone. They can simply, autocratically, make that decision. For instance, Lead Links have the domain to assign people to roles and our Chicago Office Manager role has sole authority over decisions about our office space. This is wonderfully freeing and efficient, because as the late, great Grace Hopper used to say, “It’s easier to ask for forgiveness than to ask for permission.” Being autocratic requires a couple things: lots of trust, and tight feedback loops between the autocrat and the people affected by their decisions.
Holacracy feels biological. One of the core features of Holacracy is its tension processing protocols. These happen in periodic (usually weekly) Tactical meetings. I won’t go into the details of how these work, but when facilitated effectively, they can be amazingly effective at processing tensions. It’s helpful for me to think of tensions as food, and our Tactical meetings as our digestive system. The poop is the action items and projects that result from the Tactical meeting. And just to force the metaphor, those action items and projects act as fertilizer, growing us toward the company’s purpose. The work that creates this progress tends to create tension among the team, and the circle of life repeats!
I’ve described my unique experience with Holacracy. I’m not a Holacracy expert, but I’ve learned a lot about it as we’ve been running it at Dev Bootcamp every day over the past 6 months. I imagine Holacracy can look quite different at different companies, but it does have a single constitution, and so I’m confident that the attributes I’ve described above will be shared across all implementations of this innovative way to organize a company.
Sexism and Oppression: From Oblivion to Action
This post is going to be a stream of my consciousness about my gradually increasing awareness of the oppression that exists around me, specifically sexism. This is my personal blog and I’m using this post to remind my future self about where I stood on this day.
Almost every day of my life has been spent surrounded mostly by caucasian people who aren’t super worried about paying the rent/mortgage or putting food on the table. Being a boy, particularly a shy boy, I’ve spent a lot of my life surrounded by boys and men. There have been exceptions, like when I spent 4 years working as a therapist and earning my master’s degree in marriage and family therapy. Those years were spent mainly around women. Those years ended when, at the age of 26, I decided I wanted to become a software developer.
I grew up in the lily-white suburbs east of Seattle. In 1992, I chose to attend Wheaton College in Wheaton, Illinois, a similarly caucasian suburb of Chicago. I’ve lived in that same suburb for 20 of the past 22 years. It is historically a very conservative, religious community.
I played American football in high school and college. It was a huge part of my life for those 8 years, and has had a lasting impact on my work ethic and goal-orientation. I loved that sport. It has been over 18 years since I played my last game in 1995, and I still miss playing football. Football is (almost) exclusively for men.
When I switched from “family therapist” to “programmer” in 2000, I moved from a field of mostly female practitioners to a field of mostly male practitioners. I noticed this gender-ratio difference, but I didn’t think much of it. I just knew that I loved solving problems with programming languages and I wanted to get better at it. And I got a lot better at it. I took all of the work ethic, obsessiveness, and tenacity that made me a successful (small-time) football player and threw it into becoming the best software developer I could be.
In 1997, a few years before I made this career switch, I married Staci, a feisty, charming, athletic woman who I met when I was 21. Both of us were just 23 years old when we married. My daughter Rose was born in 1999, when we were 24.
My self-induced immersion into the world of software development started a pattern of neglect between me and Staci. I would frequently pull all-nighters and while I still “showed up” as a father and husband, I was often a zombified version of myself, operating at about 25% of my capacity, most easily evidenced by the consistent loss of my short-term memory.
Our family was growing. My sons Ricky and Charlie were born in 2001 and 2004. We needed more space to live in, and we were burdened by a ton of credit card and student debt. I kept working hard to get us out of financial stress. Up until 2001, Staci worked part-time. After our second child was born, Staci stayed home with the kids. Since the day we were married, she has been the primary caregiver for everyone in our home. I’ve tended to be a grown-up kid when it comes to caregiving.
In 2009, I was a partner at a software consultancy named Obtiva. The company was doing well and I was now being compensated at a level that the financial stress in my life was starting to decrease. This is when I finally looked up from the trenches of my obsessions and started becoming more aware of injustice and disparity. Up until that point, I felt like I was sprinting. It’s almost impossible to be aware of anything other than the finish line when you’re sprinting.
Since then, I feel like I’ve been running a marathon. I’m still moving along at a steady pace, but I notice a lot more around me. I’ve noticed lots of things over the past few years.
When I was helping lead Obtiva, we were incredibly male-dominated. Since I had been there since (almost) the beginning, this realization crept up on me and it wasn’t something I had many feelings about. I tried to recruit female apprentices, but also noticed that they struggled more than the male apprentices. It wasn’t until we were acquired by Groupon and I looked around at the Chicago engineering team (circa 2011) that I was blown away that while we had over 100 engineers, I could count the women on one hand. I knew all the people hiring people, and I realized there was something systemic at work, something beyond anyone’s direct control. I knew for a fact that the hiring people weren’t a bunch of dudes consciously trying to keep women out.
I met an interesting guy named Paul Baker around 2009. On the surface, he looked like any other white guy in tech. He was the CEO of his own web design firm, but Paul had a very strong sense of justice. He kept reaching out to me with ideas we could work on together that would help disadvantaged people. Despite my passivity, he was relentless about this, and through the ideas and connections he kept throwing at me, I stopped running so hard and started conversing with people about injustice and what’s broken in our society.
Around the same time, I completely stopped running and stood still for a while. I had reached a very dark place in my personal life and I had to take some time to consider where I was headed. That’s when I discovered one of my life goals: to decentralize education. A few years later I asked myself Why? Why do I want to decentralize education? The answer came immediately: to unleash latent human potential! A year ago, I stopped and thought about the demographics of humanity’s latent human potential, and it doesn’t take a statistician to tell you that when it comes to developing software, there is an incredible amount of latent human potential in women and underserved minorities.
As I launched Dev Bootcamp in Chicago, I was very deliberate in recruiting women onto our team. I had previously failed to create an apprenticeship program that worked for women, so I figured that if we had strong female practitioners involved, that they could help create a great environment for women to learn in. As the applications poured in for our program, they were overwhelmingly male. We soon had 60 students in our space and I was sprinting again. Issues around justice and diversity blurred by as we tried to get our program off the ground and give our students a great experience.
A year later, the program is now cruising along successfully. We’re still improving and adapting, but we’re no longer sprinting. We have more time to stop and think about how to engage the tremendous latent potential that exists in the segments of our population that are currently not actively participating in technology. We’re working closely with Girl Develop It, Levo, Close the Divide, and more recently, YesWeCode.
One new aspect of our program this year is a workshop on oppression and sexism. I’ve run this workshop twice now, and it has had a powerful impact on me. There are a series of exercises that I take our students through that have helped me recognize the enormous privilege that I’ve lived with since the day I was born. The workshop gives me brief glimpses of what it’s like to be oppressed, which has actually left me feeling nauseous by the end of our time together.
The most concrete takeaway from this workshop is this: institutional oppression is rampant in our society, and what keeps that oppression going isn’t some malignant rich white dude pulling levers in an ivory tower somewhere. What keeps institutional oppression going is passivity and obliviousness. Ignoring oppression is an act of supporting oppression. I am increasingly facing oppression. I am still very ignorant. I am stumbling around, clumsily trying to be an active participant in unleashing the latent human potential that surrounds us in every city in this country.
An Old-School Solution for Today’s Skills Gap
My blog post about apprenticeship over at Wired’s Innovation Insights:
3 Phases of Beginner Software Developers
One of my biggest takeaways from launching Dev Bootcamp in Chicago in 2013 was the realization that Dev Bootcamp exists to efficiently transition people from paying to learn to paid to learn. There are few things more life-changing than that transition. I remember how profoundly it changed my life when I started getting paid to learn to be a programmer when I was 26.
Using what I learned this year about the “transition from paying to paid”, I came up with the following 3 phases that many successful beginner software developers are transitioning through in today’s software development education ecosystem.
The learner has enough context to begin to see the things they need to learn. They know the tools necessary to run programs, though they may not truly know how to use them yet. They can speak “tech” to a certain extent and are able to cobble together solutions to technical problems. They’ve completed online tutorials.
This phase is typically free or nearly free.
This is an intense period of learning where the learner gains initial fluency through immersion in the software development ecosystem. When I think about this phase, I imagine my sister dabbling with French for years, but not gaining fluency until she spent a summer in France. She didn’t come back and write epic French literature, but she could speak like a native.
In this phase, learners are typically paying or scholarshipped.
These learners now have the context and fluency to allow them to enter the world of professional software development. This phase is characterized by working on the job with a real software team delivering software. Apprentices are one-on-one with a more experienced mentor, pair programming for most of their hours together.
In this phase, learners are typically paid.
Not all of the current offerings on the market fit neatly into these phases. For instance, bloc.io costs money, but is not immersive in the same way that Dev Bootcamp is immersive, since bloc.io is a remote mentoring experience while Dev Bootcamp students spend 40+ hours/week face-to-face with instructors and many additional hours face-to-face with each other. Another example is gSchool, which lasts 24 weeks and aims to get beginners through the apprenticeship phase before graduation. Finally, there are those people who can make the transition from “free to paid” without ever paying much of anything along the way. This was my journey, and I co-wrote a book to help others make that same journey.
Head over to Quora to weigh in on which programs fit in which phases…
Thanks to Dan Croak of Thoughtbot for some helpful edits of the 3 phases.
Precious Journey, Changing Gears
On the morning of April 22nd, a group of 6 co-workers welcomed 15 students into a large office space. One of these co-workers was the Director of the office. That Director was me, and I was scared. Together, those 15 students paid about $180,000 to be in this office with me and my co-workers. We had 9 weeks to launch their careers in software development. They expected jobs. It was on the news, so even my neighbors knew about it. My reputation was at stake.
We took them through a few exercises and talked at them for a few hours. The big goal was to get them “coding” before lunch. Through a combination of good timeboxing and my discomfort with listening to myself speak, they began working through their first coding challenges at 11am. I think this is where I started losing control.
The students worked in pairs. Our workstations are actually built for pair programming. Once those 15 students started collaborating, it was only a matter of time before they would take over.
Our teachers also work in pairs. Our program has 3 phases of 3 weeks each, and teachers pair-teach a phase with each other. So, once we have all 3 phases in session, we have 3 pairs of teachers. Because it takes 6 weeks to ramp up to 3 phases, it took longer for the teachers to take over.
I am inspired by people who choose a difficult or abnormal path. Admiral Grace Hopper is one of those people, and she liked to say that “It’s easier to ask for forgiveness than permission.” That saying is written on the wall in our large office space. While they are in the space, the students and the teachers definitely live by these words.
Inside jokes started to happen. New challenges were assigned. Shoes started to come off. High fives began to break out. Students worked late into the night. Doubts began to creep in. Competitive edges started to sharpen. A generous spirit of helpfulness and collaboration emerged. Struggling students felt supported by stronger students.
Another group of students arrived. Two more teachers arrived. The helpfulness spilled over from the first cohort as they began to mentor the students behind them. These students, who were paying more than $1000 week to learn how to code, were taking the time to teach students who knew even less than they did. Their generosity brought me to tears when I first saw this “pairing board”:
With pair programming now happening across cohorts, the program was out of my control. The students were spending countless hours together, laughing, crying, hugging, fighting, forming deep relationships, and living together. But then something profound happened.
They began learning faster than we can teach. Being a self-taught software developer, I know how this moment changes your life.
We enjoy unleashing latent human potential. This means that we tend to encourage self-directed learning, even when it’s learning “dangerous” or ill-advised techniques. The fuel that drives their learning is enthusiasm, and that fuel is fed and protected at Dev Bootcamp.
The group of co-workers that do this work has grown beyond my control. As we ramped up to full capacity, the typical co-founder many-hat-removal process created jobs for 14 people from the work that just a few of us were doing originally. They are a remarkable team of people who feel safe to speak truth to power. It is an absolute privilege to work with Abi, Alex, Alyssa, Elliott, Jen, Jill, Jonathan, Kevin, Mike, Nate, Ryan, Tiffany, and Torey every day. They are learning, they are innovating, and they are the catalysts that create life-changing moments for our students.
I’m learning too. One of the biggest lessons of these first six months is learning to trust the collective wisdom of our students and staff. Time and time again, I find myself astonished and humbled at the diversity and brilliance that arise when I step back and let the collective self-organize. I’ve also learned that consensus is not the goal. I’ve learned there are times to delegate decisions, there are times to gather ideas, and there are times when clear decisions must be made by me. I’ve learned that constraints are powerful. I keep learning this. I’ve learned about essential stress and accidental stress.
Our phase assessments have taught me the most about constraints and stress. They’re painful for the students as well as the teachers. The essential/unavoidable aspect of our assessments is that they’re a judgment on someone’s progress. They could change your graduation date, and sometimes they even result in us asking you to leave the program. It’s a direct judgment of students, and an indirect judgment of teachers. There is no avoiding this stress if we want to graduate job-ready software developers. We try to be as supportive as possible so that the stress is manageable. As we find accidental stress in the process, we work to remove it.
As we begin to ramp down 2013, and I look at what we’ve accomplished, I am extremely proud. Our students are now working at Code for America, Pivotal Labs, ThoughtWorks, 8th Light, Clinkle, Treehouse, Braintree, BrightTag, Groupon, GiveForward, and dozens of other software development shops across the country. This is an amazing foundation for 2014.
While I am proud of what our students and staff have accomplished this year, there’s a growing dissillusionment among us. It creeps in at random moments when we step away from our keyboards and look around, and realize how unfathomably white and male we are as a school.
Don’t get me wrong, I think white guys are awesome. My dad is a white guy, and don’t even get me started on how great he his. I’m a white guy too, and so is my friend Yohanan. We think we’re pretty neat. Superman is a white guy. Lenny Pepperbottom is a white guy. My sons are both white guys, and wow, yeah, I’m a huge fan of them. And yet, if you stop and think about it, there is a lot more to life than white guys.
Latent human potential pisses me off. When I look at the demographics of Dev Bootcamp Chicago (currently 64% white male) and I look at the demographics of our country (approximately 31% white male), I can do some math and statistics in my head, and then I can’t not consider how many non-white-men there must be who would make astoundingly good software developers, and then I get pissed off that there is all this potential just sitting out there in a huge crowd of non-white-men.
I want 2014 to be a year that creates a statistically significant dent in the student demographics of Dev Bootcamp Chicago. This won’t happen through limiting the number of white guys. We won’t have quotas or caps or different standards or anything like that. Once a student applies to Dev Bootcamp, race, age, and gender are not something we consider. We accept people solely based on our belief that they will succeed in our environment.
This dent will happen through a strange and mysterious process called “marketing”. We have to spread the word to the non-white-guys of the world and let them know that software development is awesome: you can like your job, earn a good salary at the same time, and even work on projects that help people. Most non-white-guys in the world are women, so I’m planning to start with women.