this post was submitted on 10 Jun 2023
5 points (85.7% liked)

Experienced Devs

3956 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:

founded 1 year ago
MODERATORS
snowe@programming.dev
jmk1ng@programming.dev
drewsiferr@programming.dev
5
How do you setup a software development team? (programming.dev)
submitted 1 year ago by nibblebit@programming.dev to c/experienced_devs@programming.dev
8 comments fedilink hide all child comments
 

I think this is a struggle for many of us. Not only to re-organise existing teams but also positioning teams in a larger organisation. What team composition works for your cases? What roles are filled within a software development team, and what roles run across teams? What kind of teams are there?

I've applied teamtopologies and unfix to help communicate about our team structures, but I'm curious about what problems people encounter and what solutions you've discovered.

Some challenges I've been facing:

  • Finding or training security officers
  • Organising IT operators
  • Dealing with access control and compliance
  • 24-7 Coverage
  • Keeping Data Scientists productive
  • Avoiding superheroes
  • front-end and back-end teams
  • dedicated testers
  • The role of QA and Product

I'm curious to see a discussion :)

top 8 comments
sorted by: hot top controversial new old
[–] davetron5000@programming.dev 1 points 1 year ago (1 children)

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.

[–] nibblebit@programming.dev 1 points 1 year ago (1 children)

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?

[–] davetron5000@programming.dev 2 points 1 year ago (1 children)

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.

[–] nibblebit@programming.dev 1 points 1 year ago

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.

[–] preciouspupp@sopuli.xyz 0 points 1 year ago (1 children)

You might as well add “peace in the middle-east” to this list. :)

I’m curious what other’s opinions are.

[–] nibblebit@programming.dev 0 points 1 year ago (1 children)

Hey, if the answer is: there's no obvious solution, than at least i don't have to feel too bad 😂

[–] preciouspupp@sopuli.xyz 0 points 1 year ago (1 children)

How are you approaching this now? What's your role in this? Are you a development manager?

[–] nibblebit@programming.dev 1 points 1 year ago

I'm responsible for the engineering department at a midsized SaaS company. In the last two years, we grew from 5 to 20 engineers. We have divided our landscape in separate domains, each treated as a separate product with an API that the other domains interact with. Each domain has a dedicated development team. The end-user domains have POs assigned and the more platformy domains take requests from the other teams.

We lean heavily on automation. Each team is responsible for the development, quality control, security, delivery and monitoring. We don't have a dedicated DevOps or IT role but lean on fully automated self-monitoring systems.

We keep growing and we see that the need for specialisation arises. I'm not one for mandating a certain structure and procedure top-down, so the tools I mentioned above have helped us map out how our org has grown organically so that we can detect human bottlenecks. This we can make the boundaries of responsibilities clear and make choices that minimise the amount of 'syncing' and maximise the amount of decision-making.

Right now I see that the need for dedicated security officers, IT pros, DBAs, and analysts is starting to arise simply because full-stack devs' skills are limiting. Still, I'm unsure if it's best to reinforce the existing silos with specialists, or have a team of specialists that the rest of the org can turn to.

I also see that the complexity of our ecosystem has made it a challenge to onboard new young engineers. Additionally, the separate domains give the teams a great amount of autonomy. Our metrics show that this has dramatically improved the stability of our products in the long term. Still, it has made it more difficult and laborious to organise projects across teams.

These are just a few of the challenges I'm thinking about. Our situation obviously does not apply to everyone, but I am fishing for ideas from people in similar situations or who have seen this phase before. In my experience, every software org has unique challenges and unique solutions with unique outcomes, but I'm certain ideas could inspire other experienced programmers :)