Team/org structure

[Dominica DeGrandis]

Hi All,

I frequently get asked how teams should be organized.  And I hate that question because it's so contextual.  It depends on multiple elements (level of specialization, skillset, dependencies, size of org, specific probs org has...) and no one size solution fits all. 

Personally, I think if teams have good data revealing where the constraints and issues lay (lie?) they can evolve into the right fit org naturally (it will become obvious).  But VP's don't like this response.  They want to know how to re-org up front instead of waiting on the workflow to show them the way.

I'm curious how others feel about this topic.   

Thanks!

Dominica

[Waldo G]

Having no info to go on (and no skin in any hypothetical team), I would suggest starting with small groups of people who have lunch together, or are seen having water-cooler chats. Then, fold individuals with supplementing skills into those cores.

While this will probably start you off with homogenous groups, the thought is that they will at least get along and communicate well. The hope is that by introducing small additions, the new additions are also included in the original activity (lunch, water-cooler, etc)

There are plenty of flaws with this idea, but it's something to try.

-Waldo

--

---
You received this message because you are subscribed to the Google Groups "devopsdays" group.
To unsubscribe from this group and stop receiving emails from it, send an email to devopsdays+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Ernest Mueller]

Hmm, I thought a lot about org structure and started an in depth series on it, did a short version as a lightning talk at DevOpsDays Austin ("The DevOps Centipede"). I think it's fair to say "here's some org options, that have these strengths and weaknesses and will foster certain behaviors" as a starter point - just like in everything agile, everyone should get to their own custom implementation but providing quick-starts like kanban or scrum can get them closer to the area they want to be in to start that incremental creeping...

Ernest

--

[Charles Randall]

Self-organizing teams of qualified professionals are the most effective structure for product delivery. Imposing hierarchy is pointless and counterproductive.

--

[Ann Marie Fred]

In my personal experience, team organization needs to be more rigid for larger groups.

Many of our projects are done by "two-pizza" teams of 5-10 people.  There's little point in assigning roles within those teams; it's more important to recruit a good mix of people to begin with.  You'll need some hard-core techies, some communicators, some organizers, a manager, etc.  On these teams, people end up filling multiple roles.  Everyone has to do things outside of his or her comfort zone, and it's great fun as long as you're not afraid to fail.

Other product teams have on the order of 100 people and many inter-dependencies between different groups of people.  People may be in different time zones and have different first languages.  You can no longer have productive meetings with everyone in the room, so you have to set up communications systems.  On those teams, it's important to have experts in certain areas, with assigned job titles, so people know where to go for help.  We have Product Managers who do market research and set high-level product goals and pricing, Project Managers who deal with the red tape and paperwork, Managers who handle HR and resource issues, Security experts who know the ins and outs of various security standards and help people implement them, Component Leads who prioritize work on a weekly basis and coordinate work across teams, IT/Ops experts who are good at running things in production at scale, Continuous Delivery pipeline experts, and so on.  The goal of each role should be to remove obstacles that others are facing, so everyone can get their productive work done.  Most people actually end up filling two or three roles.  On a daily basis, the real productive work still gets done by small component teams who are experts in their own areas (usually 3-8 people).

HTH,

Ann Marie

[Janelle Klein]

The same things that make for good software make for good team structure.  We need high cohesion within a team and low coupling between teams.  If people need high bandwidth communication across team structures to do their jobs effectively, the team structures are usually pretty dysfunctional.  Likewise if the members of a team don't have a need to talk to each other, they don't really operate as a team either.

Team structure is a design problem.  Developers can be quite good at it, once they start to look at it that way.  Designing the team structure around the architecture has a lot of benefits.  However, if you have a hairball interdependent architecture, you can't build a good team structure around it.  Trying to throw more people at the problem and artificially carve it apart is often where software organizations fail.  

Trying to go faster and throw more people at it often results in going *slower*. Teams get stuck in a trap of trying to police the code with reviews and there's no way to keep up.   The best resources can no longer be productive because they spend all their time reacting to the system that is busting at the seams.  Until the team learns a way to design the system in a way that *communication* can be scaled, leaders need to keep their foot off the accelerator pedal.   We need the time to invest in that critical learning.

I don't think it's a hands off, let the team figure it out kind of problem.  Organizational design is challenging problem and we need leadership to help figure it out.  But we need leaders that listen to their engineers, that know what to look for, and have an appreciation for the challenges of our craft.

Janelle

[Manuel Pais]

Another important question when deciding team structure is if you want to keep the current skillset (with specialized people) or aim at multi-skilled people.

If the latter I recommend looking at the concept of "staff liquidity" as proposed by Chris Matts:

http://theitriskmanager.wordpress.com/2013/11/24/introducing-staff-liquidity-1-of-n/

[Ed Daniel]

I couldn't resist getting a football reference in, kind of...

While I would concur with much of this post I would like to re-emphasize the human element at play.

One of the benefits I gained from playing lots of different sports and participating in outdoor activities, especially team-based, as well as later on in the workplace, was witnessing (...and participating in) the human mechanics at play, per se.

I've been on both winning and losing teams, what you learn is that persistence plays out, of course in the real world time, budget, profitability and return on investment are some of the extra challenges to add to the 'sport'. One might want to consider binding a team to 'that' architecture.

Having the team feel and exercise a 'winning' spirit is an excellent thing to foster, when everyone is 'winning' the cohesion is superb :-p

What doesn't happen when you make good software as much as one would like to twist the argument that way is the challenge of keeping a team in the 'winning' zone. Burn-out is one issue, boredom another. For some, the remote aspects can be really tough in those instances. In all of these and other cases, trying to model that with software / software techniques can only get you so far: http://www.hackdiary.com/2010/02/10/algorithmic-recruitment-with-github/. One of the things that has emerged in management thinking as a clear advantage is the use of diverse teams - so now you've got the challenge of the diversity mix to add to your team building algorithm if you weren't already on the same page: http://web.stanford.edu/~phinds/PDFs/Dahlin-et-al-AMJ05.pdf

Team size has to be one of the most significant things to focus one's attention on, as the emotional mechanics are somewhat different: http://pelagiaresearchlibrary.com/advances-in-applied-science/vol3-iss6/AASR-2012-3-6-3633-3639.pdf

So, hope some of this resonates with you all and thanks for letting me share a reference to the football ;-)

PS. Dare I say it, looking for people with sports / team-based experience prior to and outside of their career is a useful filter but don't let that obscure people who have not yet had the opportunity to do so and would relish the chance, given the opportunity.