Why don’t we start at the beginning?

Joining an existing team with all its processes, code and history can be a specific type of challenge. It’s certainly not one I’d like to understate. Writers, designers, and I’m sure many others regularly experience an altogether different kind of terror: The Blank Page. No history, no navigation, a million directions to choose from. What do you do? How do you decide what is ”the right thing” to work on? What does “right” even mean?

When faced with this task at work, you can take some solace in the fact that you’re not working in a vacuum, like an author pondering their next great novel, smoking in front of their trustworthy typewriter. Your blank page isn’t just for your pained soul; it’s going to have stakeholders, people that rely on the words that will soon appear on it, and they need to have a say in not only the result, but also in how to get there.

In front of me now is such a blank page: I’m starting a new team at Quandoo. We will have no history & more opportunity than you can shake a stick at. Over the course of several articles we will share how we define our team identity, how we work with others and why, in the hope that maybe it’ll make these tasks seem less daunting to someone else someday.

For now though, let’s start at the beginning:

We’re team UI Platform. Our mission is to deliver and maintain tools, processes and knowledge that helps teams create best-in-class user interfaces, and makes it easy and fun to fulfill their missions.

You may notice, that’s quite a broad scope for a team. While that’s correct, I think I can narrow it down a bit, by talking about what I think is a common problem:

When adding vertical teams, it’s easy for longer term work to get buried under more pressing matters. Bugs need to be fixed, features delivered, but what about changing a low-level part of the stack? Let’s say you’re running into some of the typical problems that GraphQL elegantly solves (e.g. difficulty coordinating endpoints, inexpressive versioning, uncontrolled growth of endpoints & parameters); where do you begin? How do you get the other leads on board? Who guides long-term projects such as these that don’t strictly have a product owner, at least not in the same sense that parts of a user-facing applications do?

This is a typical task that is well-handled by a horizontal team that works with cross-functional teams. By keeping staffing intentionally on the lower end, we force ourselves to collaborate: we can’t own a design system that requires 4 full-time engineers. What we can do however, is get rid of the initial obstacles for our partners, build up processes and knowledge to work with it, do a hand-over, and offer assistance after delivery, from initial planning to code review and release strategies.

We think this is a more sustainable way of working, and I’d love to shed some more light on it over the next couple of weeks. I hope you’ll read along 🙏