Shifting from Management to Individual Contributor

When we made the decision to transition to microservices, I was the VP of Engineering at Shapeways - effectively, the head of technology in the company. My job was largely strategic and managerial - with a team of 30 with broad focuses and a director tier, the majority of my time was spent in planning with the executive team and working on strategy with the directors, with very little time spent developing software. I loved having a hand in setting the direction of our business, and in working to coordinate technology work across the product, operations, commercial, and marketing organizations, but I was starting to miss what got me into software in the first place: building things that make customers smile.

Once we decided our to make the switch to microservices, the next step was to find someone to head up the transition. This person would be responsible for delivering the transition to microservices in a way that fit our business, attempting to maximize the gains of development velocity, system flexibility, and business scalability while minimizing disruption to the core business. This person would need to have a strong understanding of Shapeways’ current business model, its strengths and weaknesses, and a solid understanding of where our new strategy was going to take us. After some thinking about where I could add the most value for Shapeways, as well as conversations with our CEO and Chief Product Officer, I decided that I wanted to give it a shot.

This may seem like a strange choice. “Why would someone who’s effectively running technology at a startup give it up to be an IC again?” Well, there were two reasons

1. We (the CPO and myself) had built tier of Directors of Engineering under me who were effectively running their areas (Application Development, Systems Engineering, and 3D Technologies, requiring little day-to-day guidance and interaction from me.

2. I had been in the VP Engineering role for almost 5 years, and was ready to mix it up and get my hands dirty with the ins and outs of software again.

In terms of the first reason - the organization almost didn’t need a VP of Engineering any longer. We had hired a Chief Product Officer to run Product and Tech, and I reported into him. This was great - he was stronger in product than in tech, so I was effectively his liaison to the technology org while he focused on building the product org he envisioned at Shapeways. In terms of the org beneath me, I am super proud to have worked alongside strong engineering leaders who had either grown into or been hired into Director of Engineering positions. These folks were (and still are) strong, capable, empathetic engineering leaders who were running their orgs without a ton of help from me. That’s awesome - that’s exactly what a Director of Engineering SHOULD be doing.

Now, with a capable leader above, and a solid trio of capable leaders beneath, I felt that I was less impactful in the VP Engineering role than I could be elsewhere. This was acknowledged by leadership - I had already been having conversations with the CPO/CEO around potential roles for me once the CPO had found his footing in the org. I really appreciate the ability to have had these open, honest conversations with leaders in my organization: it’s a privilege not always afforded by executive teams, and the trust that’s built by having them helped get us to a place where both Shapeways and myself would be happy and fulfilled.

In terms of my own personal desire to be more hands-on: this is a story that’s repeated once before in my career. I joined Shapeways in 2012, as a software engineer. Prior to that, I’d had what was effectively and engineering management position in the finance sector, coordinating a global team of software engineering to support an internal product we had built at the Firm. I was tired of management, and wanted to get my hands on again - so I did. I joined a small startup in NYC doing what I knew best at the time - bringing a devops mindset with automated testing, release management, and production monitoring to a team that needed it.

Over the months from my start date, I hired a small team of engineers to help. When our systems engineering team lead left, I took over his team. Then, when our VP of Engineering left in 2014, I was tapped by our then-CEO to step into the role. So, left management, went back to IC, and found myself back on the management track shortly thereafter. However, during that time, I had the chance to do a few things.

1. Prove to myself that I could still add value to a team, and deliver production-ready software. It’s an easy thing to talk about engineering when you’re not the one doing it every day - it’s another thing entirely to do it. I missed the work, and count myself fortunate to have had the opportunity to get back to it. And, seeing the value that my experience added to the codebase in terms of reliability and stability gave me a real sense of pride in the work we were doing.

2. Build empathy for software developers, and for their managers. Doing the same work as the people you manage builds empathy for your team. Furthermore, being a former manager who is now being managed gives you empathy for your manager! I’ve always approached management from a coaching perspective - I want us to win together. My best days as a manager were when the team would come together as a cohesive unit, solving problems, shipping software, and celebrating our successes. That doesn’t happen overnight - it requires trust, empathy, and an investment in the success of the team over your own personal successes.

3. Deliver the most value I could to the company I was joining. When I joined Shapeways, we didn’t need another manager - we needed stability, reliability, and confidence in the software we were building. Delivering those things was far more valuable than any management oversight I could have provided at that time. Having the ability to get things done from both the management and the IC seats is a great ace up the sleeve of anyone working in technology.

So, with those two benefits in mind, I started to think about my next role at Shapeways. Given that I’d been at the company for 6 years, I had a really strong understanding of our business and codebase, and knew where all the proverbial bodies were buried in both. I knew where we had been, where we were, and where we were headed, and was excited to dive back into the details and get us there. We all agreed - I would transition from VP Engineering to VP Architecture, and immediately begin working on the future of Shapeways’ technology.