Feature Development Teams

Welcome back to our series about Building Products @ Socialbakers. In the previous article we learned what Socialbakers does and how the product team works but even world-class product teams like ours can’t deliver value to customers without world-class development and engineering teams (like ours!)

We also have independent dedicated teams for Research and Data Teams for all other internal reporting and analytical needs. We’ll talk about them in separate articles when the time is right.

Engineering

In the previous article we dipped into the company structure (Product Owners directly manage Product Developers) but for total clarity here’s a list of teams within the engineering department, each with defined roles and responsibilities:

• Product Development teams (a.k.a. Feature teams)
• Operations Team
• Web Development Team
• Architects
• DevOps
• Data Parsing Team
• DataOps
• Design
• QA
• IT Support
• Security
• Customer Support

Given the amount of interesting information to share, I’ll focus only on the first of the engineering teams today and we’ll cover the rest in the following articles.

Product Development Teams (a.k.a. Feature Teams) drive every valuable feature we deliver to our clients around the world. All teams are self-sufficient regarding development and tech stack (both front and back-end tech. knowledge is fully covered). Team sizes differ but usually range between five and seven developers.

Like most fast-growing companies, we’ve made a few mistakes along the way when it comes to development team structure. Believing we could deliver more value faster, we’ve experimented with splitting teams into very small units to work on different features but that only led to teams losing self-sufficiency.

There were also unexpected delays if a crucial team member was ill/on vacation. Collaboration and knowledge-sharing also became harder to do. It was clear that larger teams are more stable, have predictable delivery velocities and easier sprint plans plus…they’re more fun to work in!

As is common in agile-driven companies, each product development team has a dedicated Scrum Master who supports SCRUM operation and continuous improvements. We can write up an article on that subject if there’s interest (let us know!), but it’s fair to say we follow the typical ceremonies: grooming of features, sprint plannings, daily stand-ups to sync team members, and retrospectives for the team to discuss potential improvements.

In our development teams, apart from the more traditional scrum-related facilitation work, the Scrum Master also supports the personal growth of each developer. This means supplying educational subject materials, flagging useful conferences, meet-ups (organized for developers by developers), events, internal tech talks, international hackathons (this is one I’ll definitely write about later!) and more.

Besides Scrum Masters, every dev. team has one Quality Assurance (QA) member directly assigned to help with testing user stories during sprint. Like most companies we experimented with several variables to try and improve the “throughput” of our teams.

Our current methodology isn’t 100% aligned with “Scrum by the book” but it works for us. In pure scrum, developers ideally don’t handover to “testers” but complete the testing themselves. However, by adding testing specialists to our dev. teams we allow developers to focus on value and speed of delivery. Sure, it’s not flawless but we are constantly streamlining to work smarter.

To further simplify development and maintain focus on hard FE/BE issues, we use a network of shared CSS coders and designers to work across teams and tasks (changing layouts, adjust UI elements, etc). These tasks are usually rapidly completed, so there’s no reason to dedicate coders and designers exclusively to any particular team. It means a bit of multi-tasking but we believe this is the best way for us to scale our efforts, and our coders love that they get to work on many varied aspects of the product.

Last but not least, there’s always exactly one Product Owner on each product development team. The PO’s job is to prepare the user stories that the dev. team will work on and to be with them every single day in order to represent the customer’s opinion in the room.

The Product Owner’s key job is to make decisions. Decisions that will affect the overall customer experience and value we deliver in MVP. In the days when we had a smaller product team, we didn’t have the luxury of dedicated POs per team, which meant one person would manage multiple development teams while continuously preparing user stories for other sprints, researching new ideas and more.

I’ll be honest and say that this was very tough for them and in hindsight, not very good for developers either. I believe that a skilled, senior PO can just about handle two teams but frankly, one team per PO is ideal.

It’s important to remember that POs need time to prepare their own work, for creative thinking, competitor analysis, problem solving or discussions with other collaborating teams. At Socialbakers, Product Owners are even the ones executing Beta programmes with our customers and sales teams, to always stay in direct touch with the world outside. All in all, POs are not user story machines and should not be treated as such.

To sum it up, ten or more people usually work on any given feature — we certainly don’t live in silos, and the work process described above has proven to be fun, practical and efficient.

Most of our developers have been with us for more than four years, and I think this retention rate shows they’re satisfied too. Have I already mentioned that we’re always looking for talented colleagues to join our team? Click here to learn more.

The last point I’d like to address in this chapter is remote vs. in-house development teams — a question many companies are unsure about. Our ten-years-long experience tells us that for us, the best solution for development management is to keep product & development teams together in one location. Socialbakers learned this the hard way.

We had acquired a company in Croatia with specific product and technical skills but unfortunately we didn’t manage to properly integrate them into our company culture. Back then, there wasn’t a true product team ever formed that would be strong enough to manage remote development.

Furthermore, as communication suffered, we lacked face-to-face meetings and knowledge sharing , product decisions were made and not passed on and developers became unsure what we expected from them. These issues prevented efficiency of workflows and optimal results.

Actually, we currently have development teams split across two offices, Prague and Pilsen, but they are geographically and culturally so close that face-to-face meetings are regular and effortless.

The key takeaway from our past and present situation is simple — remote development is a viable option only for companies with a strong product management culture and high-level of communication. At least part of the product team also has to be collocated with remote developers to act as a bridge between the product’s roadmap, the company’s decisions and remote offices.

Work environment is crucial, so we’re proud of our stylish offices which some say remind them of the Blade Runner set. Come and see them in person, grab a cup of coffee and a quick tour, just let me know!

Oh, and at the risk of repeating myself, we’re hiring!

We’ll continue describing our development efforts next time. I’ll tell you how our operations team work and what they deal with. It should be very interesting! #BeTransparent