Greenfield Org Building & Evolution

“Our goal is to build a big, successful company.” That is what one CTO and cofounder who was my boss for several years told me. It was greenfield organizational building. We were building the company for the first time and we were creating it together from scratch. We were breaking ground. I’ve been involved in this kind of thing twice. In both cases we were company building from about 10-15 people until about 1000ish in my tenure.

I joined two other companies at 800 people and 300 people and both felt less greenfield as in both there were 10-50 tech teams already and in both cases there was more of the groove of wanting to shift culture and behavior into something else instead of “breaking ground”.

The nice thing about greenfield organizational design is that you have a relatively blank slate to work with and so you have less pushback or opposing magnetic forces to deal with. There is less potential organ rejection. It’s not to say that it is easier, it’s just different. You are creating the defaults. There is less “changing of the mindsets” involved.

In the case of both greenfield startups I was at, the deliberate desire to grow meant hiring a lot of people, starting mostly in our engineering department. What I’ve learned from direct experience is that growth like this brings a lot of reorganization and reconfiguring of teams in order to assimilate the new people as they are added in. This is to be expected. It’s like you’re going on a ride. Buckle up and welcome to the people layer and don’t forget, you still have to build and deliver software at the same time as the organizational change engine revs up and the people keep arriving. It can feel exhilarating to some and stressful to others.

If you apply the one by one pattern of Dynamic Reteaming towards growth, this means that you hire people as you find them. It's typically a lot of adding people to existing teams because you want to onboard people to the culture, customs and processes that are there already and not so much let them loose on their own to flail about, alone.  You try to create a sense of belonging. You are in a “company building” state of mind. 

It’s also culture building. It’s about creating and cultivating the team and organizational dynamic. It’s about creating traditions, rituals and symbols that define your company. If you plan ahead, these can persist throughout the years serving as a binding mechanism. Some traditions could be regular hack days or retreats. Rituals might be celebrating significant company milestones together like the addition of each customer in the early days. At one company I was at, we had a tradition in our engineering group with a gong. We would bang the gong for what engineers considered significant technical achievements. Symbols are the icons that become a part of your company’s lore. Like the wearing of particular hats, or in the case of one company I was at, the rafting oar was a symbol. Our early team had a significant white water rafting trip and after that started the tradition of signing oars when we would achieve company milestones. So the rafting oar became a symbol at that company.

Onboarding program development and new hire assimilation take center stage when you’re growing and organizing one by one. And you might not have an HR team yet at the company if you’re a startup, so all of this growth and onboarding program development becomes driven by engineering.  The more people you add though the more it triggers the people who become nostalgic for the way it used to be. Pay special attention to those people — the “how do we maintain our culture people.” I was one of those people two times. Those people love your company and need to be coached through the changes that they are noticing. When your company grows by adding a lot of people it’s becoming a different, enhanced company, so you want to plan for that and also re-onboard and support the people who are already there.

After a while, as you keep adding people into existing teams, they get to know and are theoretically able to, with encouragement, continue on the ways of working from their team to other teams that emerge. The next teams you likely encounter are a result of the Grow and Split pattern of Dynamic Reteaming. It’s almost organic sometimes when you add people to a team and that team becomes noticeably too big so then it splits itself or you split it.

Should you encourage deliberate, premeditated grow and split? Should you avoid it? What do you think?  If you know that it likely comes with one by one growth, and the thought of it sounds daunting, you could proactively try to seed new teams along your growth journey to try to predictably control the grow and split. To do this you could grow just enough and then invite out two people to seed the next team.  That could be disruptive and upsetting to the original team, however and take away agency. Or maybe it can go well. It’s hard to say. I prefer to let the growth flow by allowing it to happen naturally. 

Teams can align on ways of working (like XP practices) and then you can coach them to continue those ways of working when they split. You can also encourage role alignment which is helpful for later when people wind up in different teams. If the roles behave similarly across teams it’s theoretically easier for the people when they switch teams because the behavior in the roles is similar. Fuzzy roles in software are beneficial sometimes for those who thrive on creative freedom, but are also problematic. Alignment on how we work together is helpful after reteaming: see chapter 13 of Dynamic Reteaming for practical activities to do with your teams. 

When teams get too big, they will experience delays, their meetings will take longer and their work becomes unrelated. If it bothers the team, they will talk about this and they will catalyze and own the team change. They will drive the change. You might notice the effects and bring it up to the team or they will bring it up.  Splitting the team can backfire when it creates dependencies between the split teams or when there is a shortage of specialists to go on the teams. In these cases bigger teams with the authority to organize and reorganize inside said teams are to be considered. I see this more these days due to the proliferation of specialists in our industry and the desire not to invest on multiplying the specialists so that there are enough for each team. I get that. It was easier to have smaller teams and full stack engineers when the technologies were from the Y2K era.

Sometimes teams want to and like to operate at a bigger size. I remember at one company where I was coaching 50 teams, there was one team that was noticeably larger than the others. Leaders came to the team and suggested that they split. They wanted all teams to be around the same size. The manager was alarmed and came to me for advice. She wound up pushing back on the leaders and they allowed her team to stay the size they wanted to be. They were killing it. They were building software our customers loved, the team was enjoying their work experience and they were highly organized and were keeping people informed of their progress.  Maybe they didn’t form into some rigid mold like, “teams need to be 8 people and no more.” I was happy to see that they got to own their team structure and to stay the size they wanted to be. Sometimes leaders can screw up a dynamic by messing with it.  

I like organizational evolution that is team driven. And yes, it is a privilege for teams to be able to operate like this. I know that teams are expensive. They are an investment. I think though, if your values relate to cultivating a community of people who take ownership, responsibility, and the ability to organize themselves, that you are building a culture with embedded respect.

Thanks for reading my newsletter. Here are ways I can help you.

• I’m available to work with your teams. Please email me and we can discuss possibilities. I love joining companies and helping teams grow and thrive.

• Read my book Dynamic Reteaming for tactical approaches to what I’ve written about in this post. You can find it on Amazon, Audible and at other bookstores.

• Here are my upcoming events. If you’re in Berlin or Tokyo I’ll be coming to your cities soon. Reach out if you want an in person workshop for your leadership team.

• My next book, currently called Context Switch is on Leanpub. It’s about becoming a senior engineering leader. If you’d like to read the book as it develops, check it out.