2

Our project is a single-page app powered by a REST API on the back-end serving JSON, nothing new or unusual about that.

We have specialized front-end and back-end developers that are handling individual pieces of work related to their part of the stack, as well as engineering managers (EMs) that are also specialized across these layers.

The problem is that we don't have a single person overseeing the development of the entire feature and we frequently end up in situations where one team is waiting for another one and no one really identifying this as a blocker and making decisions as to what to do next.

We've tasked both EMs to have regular sync about this but it is often failing.

What is the best way to address this problem?

One option is to look for an EM that spans both worlds but this is challenging in terms of technical expertise, not sure if there are other ways to tackle this.

Thank you

1
  • Sarov's answer basically hits it on the spot. Teams should not be defined by shared expertise but by shared goals. How big are your teams? Can they be merged into one? You also need to decide which roles should be filled by the two EMs. Maybe the team division mainly exists to give both of them a managerial role? Mar 17 at 16:11
3

Aim for cross-functional teams in the long term

Welcome to pm.stackexchange!

As @Sarov suggested, you should reorganize into feature teams. In the meantime, here are some suggestions for better coordination:

  • Ask the two teams to publish their plans in a visible whiteboard: Just by making their plans transparent, they will be motivated to resolve diverging plans.

  • End-to-end demo: Ask the combined teams to give an end-to-end demo every two to four weeks. The two teams will necessarily have to prioritize and coordinate what is needed for the demo.

  • Plan to release often: Releasing frequently is even better than just giving a demo. The two teams will be forced to prioritize and coordinate what is needed for the release.

  • Common supervisor: Surely the two EMs report to a common Engineering head. It is the responsibility of this role to coordinate the work of the two EMs. This can be done by weekly or fortnightly meetings, shared project plans...etc.

3

one team is waiting for another one

Teams should be cross-functional!

If you have one person working on the back-end and another person working on the front-end, make sure these people are on the same team! Make sure they're communicating daily and kept apace of each other's work.

If you're currently dividing teams by discipline, re-organize them to be divided by feature instead.

This also helps the development of T-shaped team members.

no one really identifying this as a blocker and making decisions as to what to do next.

A Kanban board is a useful thing for visualizing work and the blockage thereof; both within a team and, especially, as an information radiator outside the team. If you have each team maintain a Kanban board that is visible to everyone in the company, it should become much easier for managers to get a grasp of the state of things.

There are many lightweight approaches for Kanban boards, both electronic and physical. It doesn't have to be some huge process or tool.

-1

Well, when you say ...

We have specialized front-end and back-end developers that are handling individual pieces of work related to their part of the stack, as well as engineering managers (EMs) that are also specialized across these layers.

... I suspect that there are physical engineering aspects which are driving the decision to adopt such a topology.

Therefore – I suspect that "the actual decision parameters probably involve much more than the superficial software stack." Work with your stakeholders and plan accordingly. Because: "you're not the horse .. you're the cart." (And please don't be the slightest bit alarmed that I would say that.)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.