Web Team Organization Structure

Technology Devops
1

Hello,

Looking to see how other churches have structured their web team. Our communications department is proposing that front-end development should be part of Comms and back-end web development should be in IT. We have plans to move our public site to RockRMS. We will be building up this team as we only have one guy right now. My thoughts are the Web team (front-end and back-end) should report to IT. Comms should provide guidance on the visual design and provide all graphics.

Interested in seeing what other churches are doing in this area.

2

Gary, great question, and I’ll say that I don’t think there’s a ‘right’ answer.
However, I would suggest the following (we also use Rock, so my answer is most-relevant for a Rock church):

  • Get a clear, agreed upon definition for your ‘front-end’ and ‘back-end’ terms, as I see those terms used pretty loosely (in general)
  • Ideally you want someone in a ‘50,000 foot view’ spot who knows enough about each, and can help foster collaboration and communication between the different stakeholders. They may not be doing the daily work, but it’s super-helpful to enable the teams to be productive while this person helps guide and direct
  • You’ll want a great relationship between Communications and IT if you’re using Rock for both the public (website) and internal (database) functions. This can happen multiple ways, but without a well-working relationship, those teams will constantly be running into each other. IME if you have good relationships, ‘which team’ someone is on is less of an issue

In our org, we don’t really separate ‘back-end’ and ‘front-end’ clearly. Especially with a tool like RockRMS the line can get pretty blurred. For example, if someone is writing content using Lava to go in a content channel, they will need an understanding of how to find the data structures, etc. used on the back-end.
You don’t have to start with ‘front-end vs back-end’ right away, (maybe you do if you’re adding a lot of people). I’m assuming you’re talking about adding a few people (less than 10).
The closest we come is saying that back-end equates to ‘is the server running’, but that isn’t what I take your definition as.

If I had to make a delineation (knowing there will likely be overlap) for a RockRMS team (setting the expectation these two groups work closely and collaboratively):

  • A team of people that are responsible for ‘structure and strategy’; where and how you store the data, the structures you use for exposing that data for use, etc.
  • A team of people that create and manage content, such as text, graphics, images, etc.
1 Like
3

Shawn’s reply is spot-on, and I just wanted to share our structure in case it helps.
We have a few staff in IT that are dedicated to ChMS (primarily helping ministries get the most of our data, and keeping the data clean). They help with the business logic, reporting, targeting who to send communications to, etc.

We also have someone on our “editing” team devoted to handling the wording and branding of website content, specifically those driven by our ChMS (we’re on Ministry Platform, and while MP doesn’t host our public website, our WordPress site pulls all dynamic content from MP).

We have a separate “Web Team” that is under Communications. They handle building and maintaining all of our websites (and YouTube channels, a few social media accounts, etc.) and they’ll typically create placeholder pages for us, the IT staff will throw widgets on the pages that pull from our ChMS, and editing will simply add the items in the ChMS that will automatically show up on the website.

For us, this allows the web team to focus on the overall web presence (even though they don’t know anything about our ChMS) and IT focuses on data flow, data integrity, and security, and editing focuses on the specific words and art (which our design team generates).

IT winds up only getting involved when we launch new features and new integrations, otherwise it is just editing creating events, which they’ve been trained extensively on and are very good at. IT still jumps in to help with complex needs, but overall we serve as consultants more than anything.

I could see an argument for the web team to be under IT, but I prefer them being under communications personally because their focus is communication and my focus is plumbing. I feel like having web under our more “creative branch” helps them to shoot higher than I would personally as someone focused on the more technical aspect.

Overall, if we were to do it over and were using our ChMS as our website, I’d probably go back on what I’m saying and put the Front-end and Back-end folk on the ChMS branch of the IT team and still require a dedicated wordsmith to provide actual content.

1 Like
4

Thank you for your input - you both make excellent points and this is much appreciated. I’ve sent the link to our Comms team and others in our IT team to carry on the discussion. We are fortunate to have a great relationship with our Comms team. Personally, I’d like to see everything RockRMS under one team (IT or Comms) and not have a split development function. The team will be relatively small as Shawn assumed.

5

Yes, I’m a little late to this discussion, but let me add some more feedback. We are a Rock church and have been one for over 3 years. We also have a split IT team and Comms Team. Our breakdown on who handles what is pretty simple. Comms is responsible for Content, IT is responsible for everything else. Now that is very open but it is a good guiding principle and has served us well we believe. Our first Comms director was very gifted and could handle the creative side and was fairly technical and that laid a good groundwork for moving us forward. Our most recent Comms director is not technical at all but the structure was already in place and he was able to fit in.
I think the key to success is really organizational health and the support from the leadership above both the IT director and Comms director. If that is not a good situation, then whatever you do will be a struggle.
One more item… just because Comms was only responsible for Content did not mean they did not touch the technical side. That was handled based on the situation, etc. And because IT was not responsible for Content did not mean they did not create any… it just meant who had the final say on what happened.

1 Like