How Architecture Guild plays central role in crafting big tech initiatives

At the helm of all our big tech initiatives is our dedicated Architecture Guild, a diverse team of experienced individual contributors that plays a central role in influencing the direction our architecture takes. 

This group is currently gearing up to oversee one of the biggest software architecture shifts in Productboard history, which will allow us to even better meet the evolving demands of our growing enterprise customer base and consistently attract bigger companies. This exciting tech initiative has the potential to change the way product teams from all over the world build products.

So what exactly is the Guild responsible for at Productboard, and how do we operate? Let’s take a closer look. 

Who we are?

The team is led by Jiri Brunclik our Senior Director of Engineering and a seasoned software engineer who previously worked for Google. Other members include long-time Productboarders, such as me and Tomas Ruzicka, as well as newcomers with valuable experience in other fields, like Robin Pokorny. Together, we are responsible for planning, overseeing, and delivering high-value technical initiatives relating to Productboard’s architecture. 

All of us are officially attached to a specific team, where we perform 60% of our work, while the remaining 40% is dedicated to the Architecture Guild. For context, our engineering, product, and design teams are divided into three pillars — Foundations, Jobs, and Platform — and each is responsible for a core part of our product.

How we work within and across teams

The Architecture Guild is a subset of Staff+ engineers. We work very closely with the rest of the engineering teams and have regular conversations where we raise issues that need to be addressed. We’re also responsible for guidelines that shape how we’re building Productboard.

We work with a lot of non-engineering teams as well. For example, we work closely with product managers to make sure that there’s a solid vision around where our product is going versus what we’re actually building. 

The same goes for design. We talk to our designers about some of the experiences that we’re trying to create and how they fundamentally fit or don’t fit with the architecture that we’re building. 

We also hold regular architecture office hours, where engineers from across the organization can engage in technical discussions, share ideas, or raise any concerns that aren’t necessarily isolated to their own team or pillar. For example, if someone thinks that the GraphQL infrastructure that we’re using isn’t optimal and has a better idea, we can discuss it and come to a resolution.

What we do on a daily basis

As a team, we play a central role in influencing the direction that our architecture takes and what it will look like in the future. We decide what technical initiatives make it to our roadmap, and we’re responsible for communicating the reasons behind those decisions to key stakeholders across the organization, as well as addressing any feedback or concerns from our peers.

Naturally, the architectural decisions we make have a wide-reaching impact on other areas of the business. For example, moving some of our heavy processing from the frontend to the backend introduces challenges that are inherent in distributed systems. 

We now have to think about what happens when data gets updated: does it update immediately? And for whom — the person doing the updating or anyone else who might be looking at that data at the same time?

So an important part of our work is communicating the side effects of those decisions to key stakeholders, making trade-offs where possible, and negotiating with teams to find a compromise that works for everyone.  

How we shape our engineering ethos

Besides actually building our architecture, we play a crucial role in shaping our engineering ethos — the why and the how behind the what. Specifically, we help curate the following critical documents: 

Our Engineering Guidelines determine how we build our software, what our strategic engineering initiatives roadmap looks like, and the principles that guide engineers in their day-to-day activities and strategic decision-making.

Target Architecture for Productboard. Essentially, it’s a direction where we’re heading, and probably we wouldn’t be there because the world where we’re living is changing rapidly. The document itself is helpful for the engineering team if they decide where to build new functionality and in which stack, and it helps them design how it will be connected to the rest of the system.

Finally, our Technical Design Review process and Decision Log enable other engineers to make exceptions to guidelines for good reason or to suggest foundational amendments to the current architecture or guidelines. So, for example, if someone has a good reason to use Rust instead of a JVM-based language for certain types of services, this is likely how they would enact that change.

Would you like to join us? 

If you’re looking for an exciting and complex tech initiative with a real-world impact, here’s your chance. Head over to our careers page, it could be the start of an amazing adventure, and we’d love to hear from you.