this post was submitted on 10 Jun 2023
17 points (90.5% liked)

Experienced Devs

3964 readers
3 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
jmk1ng
drewsiferr
17
How do you setup a software development team? (programming.dev)
submitted 1 year ago by nibblebit to c/experienced_devs
14 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 13 comments
sorted by: hot top controversial new old
[–] [email protected] 4 points 1 year ago* (last edited 1 year ago)

Form a starting team based on skill sets and let them do the rest. Give them a project and they will tell you what they need if they feel assured that you have the capability and will to help them. You want the team to cater to the product, not to the manager because manager satisfaction does not bring value to the organization or the customer. You only need to manage more closely if for some reason you were only able to gather junior devs.

[–] valence_engineer 3 points 1 year ago* (last edited 1 year ago) (1 children)

I feel trying to structure everything "perfectly" is just micro-management and is never going to be close to "perfect" for the usual reasons top-down everything never is. My general thoughts are:

  • Employees should feel they are achieving autonomy, mastery and purpose. They'll work out all the details themselves if they're motivated and empowered to do so.
  • To that effect teams should be able to do their end-to-end work without being blocked by/dependent on other teams 80% of the time. Not for 80% of each piece of work but 80% of pieces of work they put into production.
  • The vision of the company/department and what rough path is being taken towards that vision (metrics, projects, goals, etc.) should be crystal clear to everyone.
  • Incentives (promotions, yearly reviews, bonuses, etc.) at a corporate level should correlate with driving forward business value versus bureaucratic box checking.
[–] nibblebit 2 points 1 year ago (1 children)

The price of perfection is infinite. It's not about structuring everything, and it doesn't have to be top-down. But, at some point, a team grows to more than ten people, and it's not enough to self-structure. At some point, you must agree on who is responsible for what instead of everyone being accountable for everything.

I agree with you on all points as to desired outcomes. I think it is particularly interesting that you emphasize how important vision is. I have found it difficult enough to have a medium-sized organization even come up with a vision, let alone effectively communicate long-term, medium and short-term plans to engineering teams. Aligning projects with goals and setting milestones is a great way to communicate a vision. I've found it tricky to use metrics to track progress or performance. Do you have any ideas about how to use metrics to help align with a vision?

[–] valence_engineer 1 points 1 year ago

For context, my answers are in regards to growing companies versus those past that stage that now get more value from focusing on pure optimizations. I've found that approaches which work for the latter actually hurts growing companies and vice versa.

At some point, you must agree on who is responsible for what instead of everyone being accountable for everything.

In my experience splitting into teams of 6-8 people and then assigning focus areas to teams works fairly well. Assuming you split in a way where teams are not blocking each other the vast majority of the time.

Do you have any ideas about how to use metrics to help align with a vision?

I was thinking more of business metrics which may or may not tie into vision. What metrics does the business care about (customers, revenue per customer, customer sentiment, fraud reports, etc.) and why do you think each team helps those metrics? A team may be supporting other teams but otherwise they should be pushing forward some business metric you care about and are measuring. If you're not measuring it then how do you know the business is actually doing better or worse in an area (or that a team is helping)?

[–] davetron5000 2 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 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 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 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.

[–] [email protected] 1 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 1 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 😂

[–] [email protected] 1 points 1 year ago (1 children)

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

[–] nibblebit 2 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 :)

load more comments
view more: next ›