Tag: organizational design

The Hidden Architecture of Engineering

Practical Lessons in Organizational Design

Introduction

Most engineering leaders inherit organizations they didn’t design. By the time we step into a role, the structure is already there: a mix of teams, reporting lines, and legacy decisions. It’s easy to accept that structure as “just the way it is.”

But structure quietly shapes everything. It defines how information flows, how decisions get made, how accountability works, and how fast (or slow) a company can move. The org chart isn’t just a management artifact; it’s a piece of system design.

Over the years, I’ve learned that organizational design is one of the most potent tools a technology leader has, and one of the least understood. You can’t manage around a broken structure any more than you can code around a broken architecture.

Inheriting the System

I’ve only had a few chances to design an organization from scratch, usually in early-stage startups. More often, I’ve inherited something that had evolved over time. Some were the result of thoughtful planning. Others grew like weeds.

Every organization reflects its history. Even the most ad-hoc structure is an artifact of past decisions: who talked to whom, what problems needed solving, what crises shaped the company.

That’s Conway’s Law in action: organizations design systems that mirror their communication structures. Look closely at a product’s architecture and you’ll see its org chart.

In the product engineering organization I led at Adobe, my teams were arranged by function: one group focused on building the backend, while others managed clients, core libraries, and infrastructure. This was the standard team structure at the time, but it limited our speed. Each feature had to go through four different teams, each operating on its own sprint cycle. As a result, it could take months to ship a simple feature because it needed to pass through each layer of the teams.

When I joined Spotify, the structure was entirely different. Autonomous, cross-functional squads owned features end-to-end. They deployed independently and moved fast. The system’s modularity came directly from the team design.

Different problems, different structures. Both logical in their contexts, but the lesson is constant: you ship your org chart.

Designing for Purpose, Not Precedent

Too many companies treat organizational design like a template. Someone says, “Let’s use two-pizza teams like Amazon,” or “Let’s adopt the Spotify model.” The intent is fine, but the context is missing.

Amazon and Spotify built those systems because they fit their culture, strategy, and scale. Copying the form without understanding the function is like cloning another company’s codebase without knowing its dependencies.

The real question isn’t “what structure should we have?” It’s “what problem are we solving, and what design will align our teams to solve it?”

Structure is strategy made visible. A good design aligns incentives, communication patterns, and ownership boundaries with your goals. It creates high-bandwidth communication where you need it and separation where you don’t.

And it has to evolve. The organization that works for a 20-person startup will break at 100. The one that works at 500 will creak at 2,000. Like software architecture, organizational design is never finished.

Diagnosing What’s Broken

You don’t redesign an organization because it’s old. You redesign it because something isn’t working.

My favorite diagnostic tool is simple: follow the work.

Take one feature or story and trace it from idea to production. How many teams does it touch? How many handoffs? How long does it sit idle?

Every delay is a clue. Sometimes it’s a resourcing issue. Sometimes it’s a missing skill in a team. But often, it reveals deeper misalignments: unclear ownership, too many dependencies, too little trust.

At Adobe, that exercise made the bottlenecks obvious. Each feature touched four teams in sequence, and a “simple” change could take three months due to the handoffs. At Spotify, where squads owned the full stack, the team shipped the same kind of work in a single sprint. It wasn’t magic. It was designed.

If you want to understand why your organization feels slow, follow the work.

Lessons from Team Topologies

If Conway’s Law explains why structure and systems mirror each other, Team Topologies by Matthew Skelton and Manuel Pais gives you language for designing around that reality.

They identify four core team types:

  • Stream-aligned teams own a product or flow of work end-to-end.
  • Enabling teams help others improve tools or skills.
  • Complicated subsystem teams handle specialized areas of expertise.
  • Platform teams create shared systems that reduce cognitive load.

They also describe three ways teams interact: collaborate closely for a time, provide something as a service, or facilitate learning.

The value isn’t in the framework itself; it’s in the vocabulary. It helps leaders think about flow instead of hierarchy and design structures that reduce friction instead of adding layers.

When I read Team Topologies, I recognized much of what we’d already been doing at Spotify; the authors had spent some time at the company. But I also saw patterns from earlier roles that suddenly made sense in hindsight. The book doesn’t prescribe. It clarifies.

Common Patterns and Traps

Most organizations follow predictable patterns as they grow.

Functional silos work early but become brittle later. They make coordination explicit but slow.

Cross-functional teams increase autonomy and speed but come with a higher cost. At Spotify, that meant hiring more mobile developers than most companies would ever consider. It worked because the company optimized for velocity over constraining headcount.

Centralized data or infrastructure teams start strong, then evolve into bottlenecks. You have to anticipate when to distribute those capabilities.

Matrix organizations can preserve continuity and reduce disruption when people change teams, but they also add complexity quickly. They work best when accountability is crystal clear.

And then there’s the most common anti-pattern: designing around personalities. Building an org around one person’s strengths, or avoiding their weaknesses, might seem practical in the short term. It always becomes debt later.

Reorgs as Refactors

When a structure stops working, treat the reorg like a refactor, not a revolution.

Don’t blow everything up. Make small, deliberate changes. Be transparent about what you’re solving and how you’ll measure success. Make the problems you are trying to solve clear, and how you will handle the case where the structure change doesn’t solve them.

The biggest mistake leaders make is reorganizing at people instead of with them. Change feels arbitrary when the reasoning is hidden. If people understand the problem, they’ll accept the solution even if they don’t love it.

Every reorg has a sociotechnical cost. You’re not just moving boxes. You’re changing relationships, communication paths, and identity. Handle it with clarity and care.

Reorgs should feel like system refactors, not revolutions.

Leading by Design

Organizational design isn’t a one-time project. It’s an ongoing act of leadership.

Start by mapping your current system: who talks to whom, where decisions stall, and where ownership is ambiguous. Align the structure with your strategy and your culture.

Design for clear interfaces between teams and between roles. Iterate carefully, explain your reasoning, and gather feedback.

The structure that got you here probably won’t get you where you need to go—and that’s okay. Good organizations, like good architectures, evolve.

If you drew your company not as boxes and lines in a directed acyclic graph, but as flows of information and work, what would it look like? Where would the friction be? Where would it hum?

That picture, not the official org chart, but a system diagram, is the authentic architecture you’re building every day.

To hear an extended discussion of this topic, please listen to my podcast episode: https://itdependspod.com/episodes/the-hidden-architecture-of-engineering-practical-lessons-in-organizational-design/

For more about Conway’s Law and my experiences utilizing it in organization design, see the video of my talk Architecture and Organization.

Values -> Culture -> Everything

A practical guide to recognizing, protecting, and finding the right organizational culture

In this post, I’m revisiting a keynote I gave in 2013 at the BBC Developer Conference, titled “Building a Strong Engineering Culture.” Twelve years later, my thinking has both stayed the same and evolved. I want to discuss culture, not just for engineering teams, but for you as an individual, as a manager, and as someone seeking your next role.

What Actually Is Culture?

Culture’s a heavy word. We use it in many contexts, including company culture, engineering culture, and team culture. But what does it really mean?

Henrik Kniberg, whom I had the immense pleasure of working with at Spotify, distilled it beautifully:

“Culture is the stuff people do without noticing it.”

My definition is more formal: Culture is the manifestation of the shared values of the organization as represented by the actions of its members.

The key words here are values and actions. It’s not what you say, it’s what you do. And to Henrik’s point, it’s what you do without even thinking about it.

Real Values vs. Aspirational Values

Every company I’ve worked at has had its values spelled out somewhere. The problem? Many companies have publicly stated values that aren’t really their values. These are what I call ‘aspirational values’ – they are the values the company wishes to have or believes it should have, but they may not necessarily reflect the actual behaviors and beliefs of the employees.

How do you know what your current team or company’s actual culture is? Scott Berkun created a great test:

“Can an employee say no to a decision from a superior on the grounds that it violates a core value?”

If your company has a core value of honesty to customers, and your boss tells you to lie to a customer, could you say, “I’m sorry, I can’t do that. That doesn’t align with our core values”? And would your boss fire you, give you a poor review, or say, “I don’t care, do it anyway”? If so, it’s not actually a core value.

Think about what the real values of your company are. Not the stated values, the real ones. In companies where the stated and real values matched, those values would become shorthand. Someone would say “That wouldn’t be aligned to [value]” in a meeting, and it would just end the discussion. No disagreement, no argument.

Another way to think about this: if your team shares an office, where’s the thermostat set? Has everyone determined the temperature that they agree on? A new person enters, tries to change it, and somebody says, ‘Whoa, no. This is the temperature we work at.’ That’s a shared value in action. It’s not an important one, but it’s the same principle for how you approach coding or organize your work. This is a simple example of how shared values can manifest in everyday actions, from the way you dress to the way you communicate.

The Flow: Values -> Culture -> Everything Else

Your values create the basis of the culture. The culture then influences everything else:

  • Processes: How work gets done, or how you account for vacation time, and expenses.
  • Artifacts: Physical things like signs, swag, and how offices are decorated. At Microsoft, receiving the “Ship It” award upon shipping your product was a significant achievement. It reinforced the core value of delivering value to customers.
  • Rituals: Company and team meetings, how you celebrate, or how you bring teams together.
  • Beliefs: What you believe about the industry, about product development, and building successful companies.

Why Culture Matters

You’ve probably heard the quote attributed to Peter Drucker: “Culture eats strategy for breakfast.” I agree with the general sentiment, but I’ve seen plenty of companies with great cultures that struggled as businesses, as well as successful companies with punishing cultures. Patty McCord, former head of HR at Netflix, said it better: “Culture enables success, but it does not cause success.” A great culture helps you go faster, happier, and healthier. While an amazing culture alone won’t guarantee success, it will make things a lot harder without it.

Protecting and Reinforcing Your Culture

If you have a good culture, you need to protect it. Your culture and values must inform every process and framework that guides the company’s operations. Otherwise, you’re creating conflict within the organization between what you say and what you do. If you reward something other than the culture, the culture will shift to the behaviors and values that you reward.

Start With Your Career Ladder

I get particularly frustrated when companies adopt another company’s career ladder. You’re two different companies with two different cultures! Hopefully, that other company designed its ladder to support its values. If your values aren’t aligned with theirs (they aren’t), you’ll start promoting, hiring, and rewarding based on another company’s values.

Build your own career ladder based on your values. It’s a tremendous first artifact because it informs everything else, from how many levels you have (which affects promotion frequency) to the expectations at each level.

Hiring Is Critical

Who you hire either supports or hurts the culture you have. I don’t suggest requiring “perfect” alignment or becoming a monoculture; you need diversity of thought. However, if you have a core value of collaboration and you hire someone who prefers to work alone, dislikes collaboration, and produces good work independently, you have problems.

One: they’ll be unhappy because people keep wanting to collaborate. Two: if they stay and receive raises or promotions, it sends a strong signal that collaboration isn’t actually a core value. Three: if they end up in interview loops, they will be looking for people like them due to similarity bias, which will accentuate the problem.

Onboarding Matters

You can’t simply throw new hires into a team and expect them to pick up the culture. At Spotify, when someone joined, they would spend a sprint with all the people who joined on the same day, plus a few experienced Spotify folks: an agile coach, a development lead, and a product manager. They would build features together and ship them. They would learn why the company did things in a specific way.

Because those new joiners would end up in different parts of the organization, they’d reinforce and refresh that cultural understanding. If a team started to drift, they’d help steer it back.

This intro sprint was also an excellent opportunity to identify if someone wasn’t aligned with the company values. Better to know in the first sprint than months later.

Performance Reviews and Firing

When deciding an employee’s performance as a manager, your reference isn’t other employees; it’s the rubric, the career ladder. What are they supposed to be doing? What is the expectation at this career step? You’re comparing them against the rubric because your culture and values inform the rubric.

If you don’t use that as the yardstick, you start promoting or giving raises based on something else. People notice. I’ve heard “My friend in another team got promoted and they’re way worse than me, so why am I not getting promoted?” more times than I can count. That usually means management is not being consistent.

Can you make hiring mistakes? Absolutely. When it becomes apparent that someone isn’t aligned, even if they’re fun to be around and do adequate work, they will erode your culture. You have to make a decision. It’s better to move them along where, honestly, they’ll be happier. If you aren’t aligned with your company’s culture, it’s not a happy place for you.

Team Culture vs. Company Culture

I used to think Microsoft had a broken culture. I spent eight years there. I was happy for about one or two of those. But the problem was that I wasn’t well aligned with Microsoft’s culture. Nothing was wrong with Microsoft; I wasn’t a good fit for the company culture.

I tried to make my team work the way I wanted the company to work. I convinced my management to let me build a team and use extreme programming to deliver a feature. The project was incredibly successful. When I went back and said, “Look, it worked, can we do more?” my boss said, “You’re absolutely right, it worked better than we expected. However, no, we’re not going to do that anymore because that’s not the way the company works.”

He was right. That wasn’t who Microsoft was. I wanted to turn the company into the place I wanted to be, but that wasn’t what the company wanted.

If you’re hoping your team can change the dominant culture, good luck. It’s unlikely, especially in larger organizations. It isn’t impossible, but it’s very, very difficult.

I had a different experience at Adobe. Adobe was open to change, not fixed in its mindset. When I worked on a lean, startup-like project there and succeeded, Adobe rewarded that success rather than saying, “Wow, that was great, we’re never doing it again.” Adobe had a core value (stated or not) of being open to change. That was much in line with who I am, and I was very happy there.

When Culture Shifts

Culture isn’t fixed. It will evolve with the company and its employees, sometimes slowly, sometimes quickly.

Slow, Organic Change

Organic change happens naturally. Companies grow, expand into new markets, and hire new employees. Over time, the culture will change to incorporate the new shared values and new processes required to support the larger entity. That’s okay if you’ve been careful in your hiring to ensure that new hires align with the company’s core values.

If the company’s core values are genuine, they will endure as the company doubles in size, becomes public, or changes its funding models. The culture may shift slightly, but what makes the company the company — the culture — stays consistent.

Fast, Disruptive Change

Fast cultural change occurs when a company is acquired or when the board brings in a new CEO. An acquiring company may have no interest in your culture; they’re buying you for financial or business reasons. Your processes will change to align with them, you’ll inherit their career ladder (and thus their values).

Or a new CEO comes in and says, “This is crazy, we can’t run a company this way,” and starts making changes based on their values. This change is often a deliberate choice from the board to “shake up” a company, or because the board is unaligned with the company’s values.

You often see this in startups. They hire a C-level person from Meta or Amazon, and that person starts implementing things from their prior company because that’s what they know works. An Amazon person says, “We need six-page memos for all meetings because that worked well at Amazon.” It does work at Amazon. Will it always work at your company? No.

You can hire talented individuals from these companies; they have great people there. You need those who are open-minded, who understand their experience was for that environment, and who ask, “How do I take what I learned and apply it in this new context?”

When rapid cultural change occurs, you’re either going to be pleased about it or not. If you’re unhappy, complaining or fighting the change is not a good use of your time. If you’re open-minded and don’t actively hate it, try it out. You might learn new skills or approaches. But if you’re unhappy and unaligned, why are you staying?

There’s a quote from Shanley Kane: “Broken cultures break people.”

Finding a Culturally Aligned Company

If you’re looking for a new job, it’s essential to determine if a company aligns with your values. First, you have to know your own values. What’s important to you? What are your must-haves versus nice-to-haves?

Then develop questions you can ask your interviewers. Ask about what happens when the company is under pressure. What happens when revenue is short for a quarter? What happens when a product is late? If you’re in B2B, what happens when a customer is about to churn? When a company or its leadership is under pressure, that’s when its true values are revealed.

I once joined a company where the CEO told me great stories about fixing broken cultures and the great culture he wanted to build. The team was terrific and shared many of my values, as well as the stated values of the CEO. But when the startup hit a rough patch, we started violating those stated values one by one. When I said, “I’m not going to do what you’re asking because that’s not who we say we are,” and the response was, “I need you to do it anyway,” I knew it wasn’t the right place for me after all.

So, ask for examples of stressful situations and how they affected the company’s operations and processes. If the person you are speaking to can provide concrete examples of how they reacted under stress in ways that align with their stated values, that’s a sign that they are genuine core values.

Final Thoughts

I loved working at Spotify. It’s the best job I’ve ever had. Why? The stated values were the actual values. They weren’t aspirational. That’s one reason I took the risk of moving my family to another continent to work there.

My experience with Adobe was very similar. The core values and culture of both companies were incredibly aligned with my personal values. Not only did that make me a happy employee, but it also made me a successful one, as I naturally worked in a way that was aligned with my peers and management.

Am I happy at my current company? Yes, I am. Because my values align closely with the company’s actual values. Will I be happy forever? It will depend on how the culture evolves.

I hope your company’s values align with yours. If they aren’t, I hope you’re in a position to influence the culture or find a place that’s better aligned with your values. It’s worth paying attention to. It’s worth being aware of. It’s essential to consider this, especially if you’re aiming for professional growth. If the company isn’t aligned with your values, you might learn the wrong things.

To hear an extended discussion of this topic, please listen to my most recent podcast episode: https://itdependspod.com/episodes/values-culture-everything-why-company-culture-actually-matters/

Originally published at https://kevingoldsmith.substack.com/p/values-culture-everything

Succession for Scale

Recently, I have been thinking about the role of the executive in a scaling startup.

As a senior leader in a growing company, you need to be scaling faster than the organization. You grow by scaling yourself and the leaders in your team more quickly than the business. This fact is well known and is covered excellently in such books as Zero to One and The Hard Thing About Hard Things.

Even if you are aware of this fundamental requirement, it is still challenging to recognize when you are starting to fall behind on that scaling. The people on your team, the people that got you to where you are today, who are working as hard as ever, should be doing better than they are. You may start seeing the signs: teams falling behind, tensions between groups or functions, team leaders beginning to struggle with their work, and increasing responsibilities.

You might not know what these scaling problems look like because you haven’t seen them before. Maybe you do recognize them, but your loyalty to your team lets them go on longer than they should. You can get away with that for a while.

Eventually, your boss (the CEO, the board) or your peers start to recognize the growing gaps in your organization between where you are and where you should be. In a company with a good culture, they will let you know. In a company with a less-open culture, your peers may notice but not feel like it is their place to say.

By the time the problems are apparent outside your team, it will be nearly too late.

When these problems first arise, you need to put together a plan. If you missed the early signs and the challenges are visible outside your team, you need to act immediately.

You need to bring in new talent who can help close that gap. It will take time to do that. If you choose to re-double your efforts to mentor the existing folks, you will only fall further behind. Either you missed your window to mentor, your leaders need more mentorship than you can provide, or they are not yet ready to take on the new responsibilities in their role even with mentorship.

Replacing people who have historically done well in their roles can seem cruel, and this is why it is hard. It feels disloyal to the people that have been loyal to your company and have helped to build it along with you. It is not their fault.

If you don’t make those hard choices, though, they will be made for you by the person whom your boss or the board hire to replace you.

It doesn’t have to be this way.

We have an assumption that in a growing company, people will remain in the roles they have had, and newer employees will come in below them. This assumption is one of the exciting incentives of joining a startup. It can be a career accelerator. Indeed, there are many stories of early employees at startups remaining in their senior leadership roles through rapid growth and past the point of going public. Very few people are capable of this kind of personal development, however.

Instead, we should be explicit about this challenge of growing a company. We should build a culture that acknowledges and celebrates this fundamental fact. Let people your hire know that you will support their growth, but be honest that if the company is scaling faster than they are, they may need to help hire the person who will help with the next phase.

Reid Hoffman talks about these ideas in his book The Alliance. I think Netflix has done well being explicit around the Tour of Duty in their culture. I do think Netflix is a bit too employer-focused in its attitude towards these ideas. This approach works for them because they favor hiring experienced developers and do not invest much in training their employees relative to other companies. That is another definitive decision of their culture.

I advocate for a more balanced and sustainable approach for companies, one that encourages employee development and business realities. Startups that are willing to hire at all levels of experience and support employee growth can hire and retain better. Even those companies face challenges at their scaling inflection points when company leadership changes by the new business reality’s necessities.

Suppose your company builds the concept of succession for scale into its culture. In that case, hiring your successor should be expressed as an opportunity for further mentorship and growth and not as a demotion or failure. Celebrate it as a rite of passage. Challenge the leaders in your team (and give them the tools) to recognize when this time has come, and praise their self-awareness.

Build succession for scale into your compensation structure and leadership career pathing. Ensure that the newly hired leaders train the people they have replaced to assume the role once again. If the position opens up in the future, the person may now have the skills to step back into it.

[This article was originally posted at https://nimbleautonomy.com/articles/succession-for-scale.html]

Using Self-Selection to Create Journey Teams at Avvo

Many companies are interested in experimenting with self-selection as a way of organizing their teams. I see questions about the process often in online forums. While there are some excellent books and blog posts on the topic, I thought that I would share a self-selection exercise that we did at my last company, Avvo. It worked reasonably well and with relatively little drama. If you are considering a similar exercise, you might consider this approach.

I joined Avvo as its’ CTO in the summer of 2016. At the beginning of 2017, we moved to a new team structure. The basis of the new team structure was the customer journeys through our product. The new teams were naturally called “Journey Teams.” I describe Journey Teams briefly in my talk Building a Culture of Continuous Improvement in Your Company.

Traditionally at Avvo, the development teams had been organized in a top-down manner. I had heard from the individual developers some frustration at how they were placed into teams and moved without consultation. I decided that this re-organization was an excellent way to demonstrate the more inclusive and autonomous culture that I was building. Allowing people to self-select their new team seemed like an excellent way to break from the past and set expectations for the future.

Preparation

We decided on six Journey Teams. Four were product-focused supporting customer journeys. The other two were internally focused. One Journey Team supported our developers with tooling to help them manage their services. The other internal journey team focused on supplying business analytics to the marketing, finance and sales teams.

If someone is going to choose a team, they need to understand what the team is and why they would want to join it. The Chief Product Officer and I, with our direct reports, set the number and charters of the Journey Teams.

Once we set the number and missions of the Journey Teams, we picked an initial leadership group for each team. That leadership group consisted of one senior member of each functional specialty that would be part of the team. The product teams each had a Product Manager, a Development Lead, a Test Lead, a UX Lead, a Data Engineering Lead, and a Data Analytics Lead.

The new Journey Team leadership groups were each responsible for setting up the initial scaffolding of each of their teams. The scaffolding included: fleshing out their missions, establishing their spheres of responsibilities, putting together some initial strategies they would use, and choosing their core metrics. As they made progress on these, they would review with each other and with the senior product and technology leadership. We needed to make sure that every part of the product and platform had an owner and that the plans and metrics made sense.

As the Journey Team leadership groups made progress building their plans, they were asked to put together staffing estimates on what they would need to execute their strategies. The staffing estimates were valuable as it helped me decide on what staffing I would need in the next years budget. The budget process was happening in parallel with this effort.

As we moved into December of 2016, the leadership of each of the Journey Teams had made enough progress that I felt comfortable setting the self-section exercise to happen right after the New Years break in January. At this point, the board had approved the budget. The CPO and I could figure out what staffing we would allocate to each team based on their mission and their strategy. Each Journey Team then needed to think about how they would structure their efforts based on their allocated staffing.

The Exercise

The self-selection exercise structure was a job fair with a festive atmosphere. The entire product, design, development, test, data engineering, and data analytics teams assembled. We had cupcakes and drinks. One by one, each Journey Team leadership group came up to pitch their team to the rest of the organization. They described their mission, their goals, their initial plans, and the planned size of the team. Some had already designed logos and had slogans. Each team was selling their mission to their peers. Some teams put a lot of effort and salesmanship into their pitches. Other teams had a difficult time articulating why people should join them.

After the last Journey Team had presented, every person in the room got a card. The card contained a space for their name and a list of the Journey Teams with spaces to put their order of preference. We asked everyone to fully rank their preferences just in case that would be needed.

When all the cards were filled out and collected, the meeting adjourned.

Finalizing the selection

After the self-selection meeting, the people managers from the organization met. The responses from the each of the cards were now in a spreadsheet showing each person’s preferences, the number of people currently assigned to each Journey Team and the number of people that were budgeted to be on the team.

The people managers were part of the process because they knew each of their reports interests, challenges, growth plans, and interpersonal issues. They were there to advocate for their reports wishes. They were also there to understand the process. With an understanding of the process, they could explain to someone why they didn’t get their first choice. The people managers were also there to make sure that each team had the best diversity of skills, backgrounds, and experience so that they would have the highest chance of succeeding.

The matching people and teams process was iterative. As the teams started to fill in, we had to go back and re-adjust a few times. The whole process of matching people and teams only took about 90 minutes for a 120 person organization. It went relatively quickly. Along the way, we chose to shift one headcount between teams to accommodate a developer’s professional development interests.

We were able to match 99% of the people to their first or second choice of Journey Team. In the case where someone got their third choice, we had a good explanation for them about the decision.

Once the initial rosters for each Journey Team were set, they had a chance to review and give feedback. For the cases where people didn’t get their first choice, their manager was able to discuss with them in their 1:1s.

While we were open to further iteration to accommodate any concerns that came up, it turned out that it wasn’t necessary. The Journey Teams and individuals were all content with the matching.

A week after the self-selection exercise we sent out the official announcement of the new team rosters. The teams started meeting to flesh out the initial plans and individuals moved to sit with their new teammates. We did make it clear to every person that if they were unhappy with their decision that we would help them switch.

A Retrospective on the exercise a few weeks later found very high satisfaction from the organization on the process and on the teams that it produced.

The Result

The exercise itself was a success. It had tremendous engagement from the organization. People felt empowered in the exercise and committed to their new team because it was their choice. Only one person switched teams in the three months after the exercise and only a handful in the rest of the year.

What I would do differently Next Time

The process of preparing for the exercise from each of the Journey Teams created some tension in the organization. The Journey Team leadership groups spent much time meeting together in the weeks before the exercise. The teams weren’t transparent enough about what they were doing. We as leaders hadn’t set reasonable expectations about communication. We did start to encourage them to send out updates to the organization on their progress, but it came later than it should have. Next time, I would give more guidance to the leadership teams about how they could go about their initial organizing. I would put a tighter time expectation on them, and I would make sure that they were transparent to the rest of the organization.

The presentations themselves were a bit of a challenge for some teams. We did encourage teams to make their presentations fun and to sell their missions. We didn’t help the teams with their presentations though, and we didn’t do a run through with them. The disparity in presentations did mean that some teams attracted an inordinate amount of interest. Next time, I would have a run through where each team could see each other’s presentations, and we could give some advice to help make their presentations better.

Regular Self-Selection Exercises

There were some in the organization who were so happy with the self-selection exercise that they suggested we repeat it every year. I know that there are organizations who do this. From my experience, I can see it working within a small company where most everyone already has a good connection with each other. In a small organization, it would take much less time to go through the forming, storming and norming phases. In a larger organization, regular re-organization would mean a lot of wasted time trying to get teams going.

For Avvo, the self-selection made sense at a juncture where we were doing a complete organizational restructuring. The old teams were utterly gone. It took a while for the new teams to get going, but once they established themselves, they worked well, and it made little sense to change them again. Individuals always had the option to move between teams if they felt like they were ready for new challenges. The organization was growing, and so the teams were always hiring. If we had been in a more constrained environment, we would still have done our best to facilitate smooth movement within the organization.

The core thing with an exercise like self-selecting teams or any other exercise is to be deliberate in your intent. Why are you doing the exercise? What benefits do you expect? What are the downsides? If it is successful, what will you do next? If it is unsuccessful, how will you roll it back or what will you do instead?

Conclusion

Letting the people in your organization self-select into teams can be an active driver of engagement and autonomy. The exercise we did at Avvo was successful for us and is worth looking at as inspiration for your process. If you are considering self-selection, be deliberate about what your goals are, what aspects of self-selection help you achieve them and what you might do if the goals are not met.

Building a Culture of Continuous Improvement

A culture of continuous improvement is a culture where you are always open to improving how you build and deliver. You don’t accept the status quo; you choose how to work and feel empowered to change it if it no longer makes sense. It is a people-first culture.

Having had the benefit of a culture like this at the last place I worked, when I started at my current company, I wanted to see if I could create a continuous improvement culture there, too. It took some effort, and we learned some painful lessons along the way, but we did make significant improvements to how our teams operated and how the engineering organization functioned.

As a result of these changes, our teams are able to execute at a much higher level, and the morale of the organization improved significantly. In short, we get a lot more stuff done, and we are happier doing it.

To get there, we had to change some of our frameworks, structures, and processes, or adopt new ones.

Here are some of the frameworks we created that could be helpful for any company:

  • WIGs and sWIGs: A way to align the company around a common mid-term strategy and shorter-term tactical deliveries in a way that preserves team autonomy and agile delivery. WIG stands for “wildly important goal,” and sWIG means “sub-wildly important goal.” Our WIGs clarify the midterm strategy for the company, and the sWIGs clarify the shorter-term tactics we are using to achieve that strategy
  • DUHBs: A data-driven decision-making framework that allows individuals in the company to craft a clear, data-based argument for a making a change. DUHB stands for data, understanding, hypotheses, and bets, which describes the linear process of solving a problem
  • Journey teams: An autonomous team model that gives teams more direct control over how they work, aligned with customer journeys
  • RFCs: A mechanism that allows anyone in the organization to drive large-scale change inclusively. It is a document and a process that uses the “request for comment” structure from standards groups as a basis
  • Retrospectives everywhere: A cultural shift in how we think about examining our organizational strengths and weaknesses when it comes to executing projects

Each framework builds upon the others. By making the priorities and goals of the company clear, people have the context to make good decisions. With a common data-driven process for vetting ideas, people have a good, structured way to propose changes. With autonomous teams, we can test new ideas locally and let the best practices emerge organically. With an inclusive mechanism for proposing larger-scale changes, the organization can participate in the process instead of having it pushed down from leadership. Finally, with a practice of retrospectives at all levels, the organization can learn from successes and mistakes made in any of the other components.

These frameworks created an environment that was not only adaptable and nimble, but also one where the members of the organization were empowered to make changes and were given tools to make advocating for change easier.

If there are more companies with continuous improvement cultures, it means a healthier and happier industry for all of us.

[This is a repost of https://www.techwell.com/techwell-insights/2018/05/building-culture-continuous-improvement]

Slides from my talk on Distributed Teams

Compare the Market was nice enough to invite me to speak at their tech managers’ off-site about distributed teams. This talk reflects my own experience leading distributed teams.

I was presenting to them over video. Their meeting included people in two different offices and also folks dialing in from home. Ironically, in the middle of my talk, I got disconnected from the video conference. Because I was sharing my slides full-screen and had my speaker notes on my second monitor, I didn’t notice. So I spoke to myself for about 15 minutes before I realized what happened and dialed back into the meeting. It was a bit mortifying, but the folks in the UK were extremely nice about it. I can’t think of a better example though of the challenges around working with teams who have to communicate over electronic means constantly, so it was a good illustration of the issues I raised. 🙂