Impact-driven dev leadership at Simply
Takeaways on leadership and development in a culture with no hierarchy and lots of ownership.
Impact Velocity is at the heart of our culture at Simply. It means reaching the greatest impact in the least amount of time. From the shortest line of code to the entire company structure — it’s at the base of everything we do, every decision we take. Maximizing impact velocity is our way of making sure we progress as fast and as smartly as possible on our journey to delivering the joy of learning and playing music to every household.
Developing features and leading projects through these principles, and in our unique company structure, is one of the most interesting and eye-opening things I have ever done as a developer, and the way we manage these projects is one of the main reasons why.
No managers
One of the outcomes of our impact-driven culture is that we don’t have managers, at least not in the classic sense. There is no hierarchy, no top-down directives, no single team lead that tells the rest what to do. We believe that the best person to lead any kind of effort is the one with the most context. We are all “managers” when it makes sense for us to be so.
For the same reason, we also don’t like titles, no “squares” to fit into. My LinkedIn profile says “Software Engineer”, but in reality I lead complicated projects, mentor other devs, think about how we can do things better as a team and then go write fancy blog posts about it — and so do my fellow devs.
How do we “manage” without managers?
First of all, we hire the best developers, problem-solvers, who know how to get stuff done, have good product orientation and care about the impact they make, and yet have no ego, do whatever is necessary and are amazing team-players.
Second, our developers don’t get assigned to tickets by a manager, instead they own and lead whole features themselves. The team collaboratively decides which efforts to focus on and who will do so. If an effort contains a significant amount of dev work, like a feature in the app, one of the devs takes the lead and is considered the owner of the entire execution process, looking at the feature as a whole — from planning to launch, dev and non-dev tasks alike.
This might sound weird at first, especially when recalling our context criterion from above. Product, design and data leads in our teams have A LOT of context of the feature and its goals. So why is a dev taking the lead?
Developers stand at the junction where all product, design, content and other aspects meet — where these goals and considerations become manifested, coded into life. They have the best context of all the pieces that need to come together and know how to orchestrate them into existence. But more importantly, the dev ownership here comes with very close work with the product experts and with full context of all data, goals and considerations behind the feature, and so the dev owner can not only lead the technical execution of the feature, but also tremendously impact product decisions.
Leading features this way required of me a certain mindset shift. It demanded a broader outlook that took into consideration more complexities, disciplines, dependencies, and decisions. These were my main learnings:
1. Think of everything
Ownership means thinking end-to-end about all the things that need to happen for the feature to come into existence — from planning to launching, both dev and non-dev tasks alike. It’s to focus on getting all things done, rather than getting just your part done.
The list obviously includes all the coding tasks, and related areas such as QA, deployment, monitoring and A/B testing; engineering aspects like design, architecture, scalability and unit testing; and work processes like code reviews, documentation and knowledge sharing. It also includes the planning of how and when these will be executed — defining sprint deliverables or due dates, breaking down to iterations and tasks, making effort estimations.
But in order to gain a real broad perspective you should also constantly be aware of things that have little to do with your “classic” job as a developer: Product and design considerations; Decisions or feedback that may block or speed up the development’s progress; Non-dev tasks that are integral to the feature completeness (eg copy, design, content, assets, data…); Projects other teams are working on that may conflict with yours.
Ownership doesn’t mean the owner executes everything, it means you think about them and push for them to happen. It also means being critical, actively focusing on what is really impactful and intentionally cutting corners in the things that aren’t.
2. Impact Velocity
Aim to be on the smartest, fastest path towards success. Give feedback on the requirements and suggest easier alternatives. Try to predict and prevent potential risks, bottlenecks, and opportunities, raise flags, and solve problems. Build a clear plan, but when “shit hits the fan” (it normally does…) — push for new decisions, new priorities, new plans.
The path to success is usually not clear from the get go. We want to “get our hands dirty” technically so we know what complications there are. But mainly, we prefer to test the waters early so we can get signs of impact as fast as possible, before going for the full feature. The team’s devs and product experts can work together already from the ideation phase of the solution, defining together the quickest way to test a hypothesis or reach an MVP.
3. Communication is key
To constantly move forward we need to be proactive about communication. Yes, the good old talking-to-one-another is the best way to get stuff done. It ensures that everyone is on the same page and has clear goals in mind. It’s how we solve problems, answer questions and handle dilemmas. It’s our way to share ideas and feedback, make good plans and reach smart decisions fast. Whatever form of communication works for you — Slack, Asana, recurring sync meetings, or just a small face-to-face chat which is also nice.
In Simply, leadership is not hierarchical and ownership is not a delegation of responsibility or power. Which means that you’re not anyone’s boss.
4. The Team
As I’ve mentioned earlier, leading the effort doesn’t mean doing everything on your own. The deliverables are still the team’s responsibility, and you own the overall process, not every fraction of it. The team’s job is to reach the destination together, and you are simply carrying the flag, with all your teammates marching right there with you.
Ownership in Simply is not hierarchical and not a delegation of responsibility or power. This also means that you’re not anyone’s boss. We lead through servant leadership, which means you’re there to serve your teammates, not the other way around. We offer advice rather than instructions, explain rather than decide for others. We show trust and assume good, while still asking the hard questions.
Take home
You might be wondering “well that’s all bright and shiny, but can any of this work in companies with different structure or culture?”. Well, yes! To be honest, none of the key principles I described depend on a non-hierarchical structure or multi-disciplinary teams. It’s actually exactly the opposite — the lack of these principles might fuel the unnecessary expansion of more hierarchy, more managers and more departments in an organization. There’s no need for massive structural changes for that to work. Pushing forward through lots of communication and applying end-to-end ownership in day-to-day work can benefit developers and managers in any organization.
Regardless, if you’re curious for more or have questions on how we do things, feel free to reach out to me or anyone else here at Simply.
