Last year Publicis Groupe acquired the marketing technology company Epsilon, and as part of the deal Epsilon would own the product I’m working on (now called Epsilon PeopleCloud). In February Brian Trevor, the Senior VP of R&D, visited the Groupe’s New York office to present his plan for the future of PeopleCloud. More importantly, he also shared details about his management style and the leadership team he organizes to explore how his teams can be run more effectively. Brian Trevor hosts a book club in his leadership team, and recently they went over the book Extreme Ownership.

Wanting to start off on the right foot with Epsilon, I read the book to make sure that my mindset on managing teams matched that of the leadership team. Extreme Ownership was written by Jocko Willink and Leif Babin, two Navy SEALs who served in the Iraq War. The book describes a framework for leading teams developed in the years they spent managing battlefield situations, dealing with bureaucracy, and training the next generation of soldiers. Each chapter discusses in depth a different principle regarding leadership, the first of which being the namesake of the book, Extreme Ownership.

Under the principle of Extreme Ownership, leaders must assume responsibility for everything that happens in their team. When things go wrong, it is unsatisfactory to attribute a team’s failure to bad luck or poor execution. Instead, leaders must admit their own shortcomings to the team, and by claiming ownership over the situation it builds the team’s trust in the leader. Additionally, the leader must take those lessons learned and provide the team with the tools required to succeed in the future.

After reading about Extreme Ownership I thought about how I could’ve done things differently at my previous job, as an engineering lead at a startup called Makr. Looking back there were many factors playing against the company: limited monetization opportunities, DIY not being as far-reaching or long-lasting of a trend as we intially hoped, our inability to secure millions in venture capital to build Makr into a proper product (I’m looking at you, Canva!) But those were all things out of our control; there were many others I could’ve done something about but chose not to.

When Makr’s CTO left in 2014 I had an opportunity to take his position for myself, similar to when Ned Stark saw a vacant Iron Throne before the events of A Game of Thrones. However I was young and inexperienced, and I wanted the offload the duties of answering to VCs and managing an engineering team (which consisted of one freelancer and myself) to literally anyone else. I had but a single year of experience writing software in a professional manner; if anything was a bad sign, the VP of Engineering we ended up hiring had even less.

While Makr was working a new product our VP of Engineering wrote a new orders API from scratch, with the plan to transition the entire backend to a new tech stack. It sounded like a good idea at the time, but we ended up with two services that couldn’t share critical information with each other, and our mobile app was burdened with the task of communicating with two sparsely related systems. The situation with our backend was so bad that when we got a new team and set out to create a website version of Makr, we decided to write everything from scratch again instead of trying to solve the puzzle with the existing pieces. There were always talks of going back to a unified backend, but “eventually” turned into “never” when Makr ceased operations.

Looking back from today, I realized what could’ve been the root cause of my VP’s actions: if he couldn’t figure out how to use the existing backend he had no choice but to give up and create a new system, one he would have a better understanding of. Instead of assuming the VP of Engineering would figure things out on his own, I should’ve spend time asking if he was struggling getting the system to work and make adjustments to remove the issues blocking him. It turned out the situation wasn’t unique to him. When Makr was acquired by Staples we replaced our VP of Engineering with a team of engineers from Staples, and like before I left them to their own devices resulting in the same problems.

When asked what caused Makr to fail, people may cite a weak business model, a bad product-to-market fit, or a lack of marketing resources. I would argue that bad technology lead to Makr’s downfall. I had a chance to stop our technical issues from compounding, but instead I let those problems fester for years on end and I dismissed my former teammates as the source of those problems. That’s the opposite of Extreme Ownership.