The Science of being super
Superology is now Happening
Empowered work

You're not the boss of me: empowered teams and where to find them

It takes an empowered team to deliver a great product. And this is just how we like them at Superology.
Superology meeting

I named this text “You’re not the boss of me” after a talk I held at last year’s SuperMinds conference, partially because I really like the band They Might be Giants and partially because of its clickbait quality. It serves as a good intro to what I wanted to talk about – teams with no stakeholders.

To give a bit of background, I worked in an agency for just a smidge over a decade. First as an iOS developer, then as a team lead and in a few other roles, I eventually moved into product space as an engineering manager for the team that develops the SuperSocial platform at Superology.

Once I got over the initial culture shock and recovered from the agency mindset, there were a few things I wanted to know better before moving to a product team.

What’s a vertical?

If you’re in almost every product company longer than 30 minutes, you’re bound to hear someone mention a vertical or a similar name that basically describes a product team within a larger organisation.

The background of these teams comes from an organisational issue every large project eventually must cope with – how to split work when you start scaling your team up. Development often requires feature teams to emerge until they deliver that feature and move on to the next one. Still, in a product company, more commonly, you will form teams around a smaller part of the app that will continue working for much longer, even once the feature is delivered. And I can’t stress this enough, delivered does not mean finished by any means.

A vertical team is named that way because they are cross-functional and will have a full stack of developers, designers, and product managers rather than a feature team which might be constrained to a specific tech (e.g. iOS team).


Stakeholder who?

A somewhat uncommon model of working, especially for my own team, is the fact that there is no single stakeholder who decides what will be the next feature. Instead, based on what we think might perform well, the team decides to create an experiment, measure relevant metrics and take input from our actual stakeholders – our users. We often say that data is our stakeholder, or users are our stakeholders, and our success is measured only by how well the users receive what we deliver.

Compare this to a directional model with a well-known stakeholder, a person who has requirements, a project manager that refines them, and possibly a project lead that might estimate and create a specification, which is then passed on to developers. Such a team often does not have the power to decide the direction of what needs to be done, unlike an empowered team described above.

How do you decide what to do?

The answer to this question is rather simple – and we call it discovery. This process envelops a lot of smaller processes which will eventually give us a go for developing and delivering a feature:

  • Discovery and ideation meetings: where we discuss ideas for further development
  • User interviews: where we try to find pain points, missed opportunities and places or improvement
  • A/B tests: where we sometimes validate feature ideas on the smallest prototype possible and perioically even test feature refinements
  • Market research: where we try to figure out what the competition does, how to gain an edge over them etc.

All these things converge together to form one continuous process that – since we might revisit an existing feature during its lifetime – does not have a very clear start or an obvious end, and that’s what we call discovery.

Key takeaways

To sum up the process of having no boss, we can refer to the cycle below:

  • Start with an idea for a feature.
  • Define the smallest amount of work we can use to validate that feature, usually in the form of an A/B test
  • Either implement the feature or discard it.
  • Continue learning from the above lesson to generate new and better ideas and return to step 1.

Further exploration

Like many companies, we’re inspired by success stories in the industry and if you want to learn more, here are a couple of books that’ll show you the way.

Further exploration - books

Latest Posts

How more downtime drives creativity and innovation

How more downtime drives creativity and innovation

As more and more companies are pushing creative ways of implementing a more sustainable work-life balance model, we're opting for unlimited vacation. That's just...
BEAM me up, Scotty: A short talk with Saša Jurić

BEAM me up, Scotty: A short talk with Saša Jurić

Saša is a household name in the Elixir community, and his book, Elixir in Action, is a staple we at Superology already use for our backend developer onboarding...
How we use data to advance user experience with ClickHouse

How we use data to advance user experience with ClickHouse

Superology uses quantitative data to create reports, analyses them using statistical tools, and creates randomized experimentation processes. We use this data to...

We're hiring!

We're hiring

There are endless opportunities for improvement. We need great talents to make it happen.

But first, cookies
This site needs cookies to function. We all do. Along with the necessary ones, we would like to use additional cookies to improve your experience.
Necessary Cookies
Analytics Cookies
Read more about it in our Cookie Policy.