Development

Subteams but not silos
We believe that it’s best to work on projects with small dedicated cross-functional teams. Each subteam has someone with backend skills, someone with frontend skills, and someone with design skills, and usually one person can cover two areas. This enables each team to work independently on big challenging projects. At the same time, cross team exchange is super important to prevent knowledge silos. We combat silos with a strong sharing culture: Slack and Confluence help, but ultimately it’s about face time. Everyone is expected to present new findings and trends at our weekly Dev Exchange meeting for instance, and there are ad-hoc meetings for additional topics such as DevOps, Design and Technical Roadmap planning.

Agile processes
We’re an agile and highly incremental company. It’s built right into the name. That said, our 3 dev teams all have their own versions of what agile means to them. All of them have standups, all of them do retrospectives, all of them break down their work packages into digestible chunks. But just how far to take it is entirely up to teams. Sometimes teams will try out a more structured, Scrum-like approach. Sometimes they will ditch it all and not have a process at all for a month. Kanban is probably the preferred way most of the time, but in the end it also depends on the project at hand. A new team member will be able to influence the process too.

Specs and Visual mocks
When it comes to feature work, we do like to plan ahead a bit. While a single screen can be adjusted easily even after it has been built, changing an entire sequence of user flows is time consuming. We try to get it right by having a visual mockup that we all can agree on upfront. The Design Metateam helps!

The same applies to specifications. We don’t believe in heavy upfront planning, but starting a 3 month project without a goal or plan wouldn’t work either. We do create initial specs together with Product Management, and have a shared kick-off meeting after which we work together on refining user stories where needed, breaking up technical pre-requisites into tasks, and so on. From there on it is an iterative process again though, and of course specs can change.

Our technical vision is pretty simple:

We want a codebase and technical infrastructure that makes customers and developers happy.

Making customers happy is typically influenced by us being able to deliver features and improvements quickly, to fix bugs, and to make it an overall smooth and performant experience. And of course it has to be secure.

Our customer sweet spot is 100 to 500 employees, and we do support up to 2000 or 2500 users in one account without the system falling over (it doesn’t have to be super-speedy though at 2000+ users anymore). This is not going to change. We are not aiming for larger clients in the next couple of years. We want to serve far more clients rather than larger clients. This does of course have implications for the codebase

At the same time, we want our developers to be happy and proud of the codebase. Anything that really pains us should get addressed over time, using a ROI-based approach. We don’t always have to tackle the most hairy thing first, it can make sense to address some smaller pain points first for instance, but over time everything should be fixed.

Wait, that’s it?

Those are admittedly not very concrete goals. What about hairy technical tasks? We do have plenty of them, and we’re talking about them for instance at the weekly dev exchange, and tackle tem one by one. It’s an incremental process, and there is currently no huge (nor secret) 5 year technical goal that we have to achieve. It’s a steady flow of looking at challenges and addressing them

This may sound not quite as “the grand vision” at first. But looking back at technical goals we had at previous employers, those were also largely painpoint driven, and if they seemed grander then it was typically because the products there stacked up worse and had more room for improvement. SI has it’s share of quirks, but compared to any other dev project we’ve been on, we’re stacking up really well!

So, back to the original vision. We’re working towards a great codebase to be proud of, and we want to work efficiently to make customers happy. We’re on a very good trajectory, we can spare more time on making the code base better than ever before, so to achieve a vision of happy customers and happy developers, we get cranking and fix pain points. We may not have the big hairy goal that some other companies have, but unlike many others we do put “developer happiness” right up there. That’s also something.

Our Tech Stack is always evolving, but the rough features stay the same: We host on Google App Engine (using Java) and our frontend is a single page application that’s mostly React with some remainders of our previous Angular codebase still living on. We use a plethora of build tools, backend services and frontend libraries too to make SI happen. Take a look at our detailed Tech Stack page to learn more.

We believe in empowerment and independence. That’s why each of our teams can have their own version of the process. Sure, ultimately we all play as one big team, but the details can be different. This allows for “friendly competition” where every team experiments continuously, and presents their learnings at our weekly Dev Exchange meeting for the others to learn. Continue reading about Team Techno, Team Outlaw and Team Green.