The structure of any software development team heavily affects the quality of products that the team delivers. For me personally, the contrast between the way we work at Kinja and the previous news sites and web agencies I worked for is both surprising and inspiring.

I recently gave a talk at a meetup called Design2Business here in Budapest, where I talked about how our tech team’s organization helps us make better products, with less internal strife. This post is the content of that talk. It’s not meant to be a comprehensive guide on feature teams, other people have already written some excellent work on those. But it might give you some ideas on how this structure could benefit designers, developers, and even stakeholders - and how you could implement it at your organization.

The tribes dividing tech organizations

Most of the companies I’ve seen tend to be structured the same way: people who have the same job are grouped together. For example, in a web design company, you’d have the backend developers, the frontend developers, the designers, the product managers, sales, HR and so on.

It’s easy to imagine how these groups could form organically - grouping up based on likeness are something that humans just seem to do when left to their own devices. It’s always easier to communicate and make friends with someone who shares a lot of your expertise, and has the same kind of problems. Groups like this are called silos, and they are harmful for multiple reasons.

First of all, homogenous groups like this can start becoming echo chambers. Communication is always easier inside these groups than between them. So when you have a problem, you talk it out with people inside your silo. This only reinforces and amplifies problems instead of solving them. Grudges start to build and the silos dig trenches between each other.


Also, when you think about your colleagues in labels, it’s easy to appropriate every slight to the group instead of the person.

Silos reinforce stereotypes and conflicts. This, in turn, degrades communication even more, creating a downward spiral of hostility.


When you have silos who don’t like to communicate between each other, it’s a natural defensive mechanism to start creating more and more documentation. At least that way, when the project misses its deadline, which it usually does, you can point at the other silo and say it’s their fault. Documentation is not inherently bad, every team needs some of it, but it is of zero value to your users. Our readers don’t care at all whether Kinja’s designers made 300 pages of incredibly detailed specifications for the developers or not. The only reason for meticulously writing everything down is that the silos need to cover their asses once it becomes apparent that nothing gets delivered, at least not on time.

Communicating through long-winded documents also pushes the workflow towards a waterfall structure. The waterfall method is when first management decides what problem they need solving, and what solution they think will solve it. Then they set this solution in stone, and hand it off to the designers, who do their best to make something that works within those confines. And then, they hand it over to developers, who, again, try to make sense of the pile of specifications, and try to create something out of it that makes some sense.

The most important information, the goals of the project, somehow tend to get lost inside this mountain of over-explaining. The further down the development pipeline you are, the less sense the decisions seem to make, because their context is often omitted.


And if, down the line, it turns out that something needs changing, you have to get approval from all the previous stages, which probably means you’re in for some painfully long meetings, and update all of the docs, which, again, takes a lot of time and could introduce errors and inconsistencies.

This method is ancient. It was designed manufacturing businesses, for factories with assembly lines, and it is absolutely unusable for software development, because of one simple, but hard-to-swallow reason:

You have no idea whether a piece of software will solve your problem until you actually deliver it.


The only thing the waterfall method achieves is that it drags out the project so long, that by the time you find out a certain solution doesn’t work, you have already spent too much time on it.

Of course, there can be silos even in organizations who adopt some agile project management framework. Silos and the waterfall method don’t always go hand-in-hand, but it’s important to realize that they can reinforce and attract each other. And both will slow down your software team.

So what can you do instead?

Kinja’s Tech and Product Team is set up into feature teams: small, cross-functional teams that have all the resources and decision-making power to deliver features independently.


Each team is tasked with a business goal, preferably one that can be directly measured, and they are free to attain this goal in any way they see fit, within reason. If it turns out that the approach they chose doesn’t work, they can scrap it and try something completely different. Instead of making large guesses about what works, we can create quick prototypes and actually measure their impact.

This still doesn’t require every team to have a full set of disciplines. We have teams whose job is to refactor code, or make tools for other teams to use. These teams can consist entirely of developers, since they don’t depend on others.


For example, we have a team called Discovery Team, whose goal is to increase the amount of recirculation traffic on Kinja sites. (For those not familiar with the term, recirculation traffic is when one of our readers, after reading an article, or watching a video, continues through to another piece of content instead of leaving the site.)

In Q4 2017, the Discovery Team consisted of a product manager in Chicago, two designers in New York and Chicago, a frontend engineer in Budapest and two backend engineers in New York- a full set of disciplines.

The key takeaways from this team structure are:

  • Each team has, at most, 7 members, but usually even less than that. This keeps meetings manageable, and encourages casual communication between team members. Jeff Bezos’ Two Pizza Rule is a good guideline to follow: teams should be small enough that ordering two pizzas is enough for everyone to get a couple slices.
  • Teams are focused on business goals and are empowered to make their own decisions.
  • Teams work on one main project at a time. This reduces the need for distracting context-switching.
  • Instead of relying on extensive documentation, the small size of these teams encourages the use of informal shared knowledge.
  • Team members are split between offices. This ensures that offices don’t become their own silos.


Of course, feature teams are not entirely free from their own set of challenges, either.

  • Given the high level of independence our teams have, it can be challenging for management to make long-term predictions.
  • A strength of discipline-based silos is that they develop a sense of camaraderie and facilitate knowledge-sharing between silo members. This is a bit harder to do in feature teams. Our solution is that we also have regular meetings for members of each discipline. These work well for sharing best practices and experiences. They also seem to work well as group therapy sessions.
  • Because teams are split between offices and time zones, day-to-day communication is more difficult than it would be with co-located teams. We mitigate this by using Slack, lots of videoconferencing, and trying to give each of our colleagues a chance to meet their co-workers in person once a year. No matter how good telepresence tools get (and it feels like they still have a long way to go), nothing gets people on the same page as well as being in the same room together.


The benefits to the design process far outweigh these drawbacks, though. Feature teams allow our designers to shift to design prototypes quickly, and this structure makes discussions with developers and product managers a lot easier and faster. The role of designers in teams like this is very different. Instead of being expected to know the perfect solution before starting the project, designers can experiment and iterate together with the team.

Feature teams also help create a culture where design decisions are based on data from actual test results. This, in turn, makes meetings easier: instead of having to figure out the best design beforehand, the team can deploy multiple possible versions, then test and see which one actually works best.

By making casual communication easier, feature teams also bring people from different disciplines closer together. Everyone on the team can voice their ideas, and understand the reasons for design decisions instead of having to accept them at face value. This creates a culture of inclusion which both raises the quality of the products the team delivers, and team morale.


But perhaps the biggest benefit is how much faster feature teams can react to user requests. The fact that the teams are empowered to make their own decisions means that there’s less need for lengthy approval rounds with stakeholders. And it’s also easier to update the documentation, because there’s less of it. Teams can just figure out a solution and deploy it the same day.

Overall, this structure enables us to have better conversations about design and nudges the team toward a better and more efficient mindset. I hope this post helps inspire you to try out something like this at your organization.

If you’d like to find out more about feature teams, I’d suggest you start with reading the book “Lean UX” by Jeff Gothelf and Josh Seiden.