this post was submitted on 10 Jun 2023
17 points (90.5% liked)
Experienced Devs
3954 readers
1 users here now
A community for discussion amongst professional software developers.
Posts should be relevant to those well into their careers.
For those looking to break into the industry, are hustling for their first job, or have just started their career and are looking for advice, check out:
- Logo base by Delapouite under CC BY 3.0 with modifications to add a gradient
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
At sub-100 developers, what I have seen work is to align dev teams based on company organization structure, so that each part of the company has a dev team to support the internal products they need and can develop expertise to help when coordination across teams is necessary.
The size of these teams is commensurate with the priority of the function and its internal products.
Like any organizational method, you need a strong vision from the top, clear priorities, and a product roadmap that makes sense.
That's interesting. One of the problem for onboarding new engineers is they miss any domain knowledge of our product and building that end-user sensitivity is difficult. Embedding devs with sales,support etc does address this.
What are some problems you've experienced with this approach?
The downsides is when you need to do something cross-functional it requires a different approach. What I have seen work is that you spin up a temporary team to own the delivery of the cross-functional project then have VP/CTO give all teams priority about helping the cross-functional team, e.g. the x-func team will say "I need support from finance and marketing" and those teams would agree to help out via 1 dev for 2 quarters (or whatever).
It requires a lot of clarity from management and agency from the cross-functional team.
That sounds like a healthy arrangement! I like this idea of x-func teams that are set up on a temporary basis. We do this often implicitly, but it's good to have an explicit process around it.