Ask HN: Those in smaller tech companies, what's your org chart? Is it working?
I manage engineering for a company that's grown from about a dozen people to around 70, more than half of which is in product and development. Our structure has evolved organically during that time, primarily centered on technology-based teams (mobile, web, backend, etc), however we recently pivoted to an interdisciplinary product-oriented model.
In the course of evaluating this change I was surprised by the lack of available reference points - there are numerous opinion pieces on org design, but real world examples are few and far between.
Those of you in companies of 50-200, how is engineering structured? Is it effective? What would you change?
3 comments
Similar size company and over the past 2y we transitioned from technology based teams to stream-aligned teams that include engineering, product, and design within each team. The book Team Topologies is a good reference for this and fairly quick read.
In my experience, the pros of stream-aligned teams vastly outweigh the cons. The major pros are reduced cross-team dependencies and fewer hand-offs, more ownership over work, focusing people on a narrower set of customer/business problems, and that stream-aligned teams are easier to refactor and decompose as the organization grows.
What I learned along the way is that you will still have some cross-team dependencies based on technical expertise. So you will benefit from your engineering leaders explicitly and regularly discussing these needs, then incorporating some resource sharing into their plans. For instance, you might have an engineer who really knows one area of the product or technology brought into another team's kickoffs and design reviews or even joining the other team temporarily.
In my experience, the pros of stream-aligned teams vastly outweigh the cons. The major pros are reduced cross-team dependencies and fewer hand-offs, more ownership over work, focusing people on a narrower set of customer/business problems, and that stream-aligned teams are easier to refactor and decompose as the organization grows.
What I learned along the way is that you will still have some cross-team dependencies based on technical expertise. So you will benefit from your engineering leaders explicitly and regularly discussing these needs, then incorporating some resource sharing into their plans. For instance, you might have an engineer who really knows one area of the product or technology brought into another team's kickoffs and design reviews or even joining the other team temporarily.
I worked for a company that grew from about 30 employees, 4 of whom were programming/networking. As we grew, the network side grew to 6 permanent and development to around 15. We stayed at those counts until we hit nearly 200 employees and were acquired by a much larger company. Organizationally, I was responsible for development and reported to the COO. Network reported to a separate manager also reporting to the COO. I had responsibility for audits etc., so the network group was also dotted line to me. I chaired the IT committee which included the COO and all operating managers. The committee was responsible for product. We were very successful with our product development. Finally, I reported to the board of directors quarterly. It was a fun experience. Best of luck to you.
Theres a book called team-topologies that recommended a lot for this.
We made the switch to cross functional teams at around the same stage as you. I think a lot of lessons are really org-dependant, but highlights from me:
- Team/Pod effectiveness varies hugely. When most team-members "get" what they are trying to do and actively participates, it works amazingly well. Where there is gaps in communicating things tanked. The early symptoms were usually the team adopting more complex org frameworks, more detailed specs, obsessing over QA processes, meeting schedules etc. It was initially tempting to view this as a problem with the org structure, definitely seemed like it at the time. But after a bit of time the root cause was obvious. The nice thing is it manageable as isolated as long as you don't overreact
- Relatedly, you need to put a lot of effort into making sure everyone knows what the goals are for a team and its very clear what a win/loose looks like. Also since most people will be taking on more responsibility, mentoring becomes very critical. So you need good mentors with time to dedicate to it. Its easy for a team to get stuck in limbo and for people to feel frustrated.
- Since more junior people are put in positions of responsibility, gotta watch out for overly theoretical approaches & lets use framework-of-the-month behaviour. Both on the product & engineering side. Another reason for goals & win/loose being clear and mentoring.
- It really helps for teams to broadcast updates & lessons learned to other teams periodically. People knowing who helped to build what was good for everyone.
- QA people turned out to be some of the best "glue" for teams
- People jumping around different teams was surprisingly practical. Some people like doing this. Obviously didn't force the people who don't like it.
- People currently struggling but just maybe under your radar will suddenly feel the heat if they are letting their team down. It can be traumatic for them. Its worth keeping an eye out and jumping in to assist.
We made the switch to cross functional teams at around the same stage as you. I think a lot of lessons are really org-dependant, but highlights from me:
- Team/Pod effectiveness varies hugely. When most team-members "get" what they are trying to do and actively participates, it works amazingly well. Where there is gaps in communicating things tanked. The early symptoms were usually the team adopting more complex org frameworks, more detailed specs, obsessing over QA processes, meeting schedules etc. It was initially tempting to view this as a problem with the org structure, definitely seemed like it at the time. But after a bit of time the root cause was obvious. The nice thing is it manageable as isolated as long as you don't overreact
- Relatedly, you need to put a lot of effort into making sure everyone knows what the goals are for a team and its very clear what a win/loose looks like. Also since most people will be taking on more responsibility, mentoring becomes very critical. So you need good mentors with time to dedicate to it. Its easy for a team to get stuck in limbo and for people to feel frustrated.
- Since more junior people are put in positions of responsibility, gotta watch out for overly theoretical approaches & lets use framework-of-the-month behaviour. Both on the product & engineering side. Another reason for goals & win/loose being clear and mentoring.
- It really helps for teams to broadcast updates & lessons learned to other teams periodically. People knowing who helped to build what was good for everyone.
- QA people turned out to be some of the best "glue" for teams
- People jumping around different teams was surprisingly practical. Some people like doing this. Obviously didn't force the people who don't like it.
- People currently struggling but just maybe under your radar will suddenly feel the heat if they are letting their team down. It can be traumatic for them. Its worth keeping an eye out and jumping in to assist.