When an Engineer Has to Make Product Decisions

Problem

I transitioned from being an IC in a large company to the role of an architect in a startup tasked to re-architect the entire scalable back office. The task transcended the regular responsibilities within the engineering organization, and I became the sole owner of the company-wide product roadmap. I was suddenly in a position to make decisions affecting functions like Sales, Content, Engineering, etc., thus having a direct impact on the budget, hiring, team structure, etc. Needless to say, I was expected to stay technical and hands-on, on top of everything else. While wearing many hats is not uncommon in the startup world, it was a new experience for me that made me further improve my skills.

Actions taken

It was not easy to prepare for an all-encompassing role like the one described above. I was reading avidly -- books, blog posts, articles -- anything that could provide me with a better understanding of how I could approach my new role and responsibilities. Twitter became an indispensable ally as I was able to follow the greatest minds in the industry and learn from their experience, along with Slack channels where I could connect more with my peers. I was insatiably learning about new methodologies and frameworks and trying to apply them in my own area of work.

However, nothing could replace the coaching experience I had with my mentor. He was the CTO of a large company, and did not only provide me with mentoring sessions but co-run with me all the product meetings taking place weekly. The company hired him to help me adjust to my new role, learn tricks of the trade rapidly, and thus make the best decisions in the interest of the company. For the whole first year, he was the most important person who helped me steer things in the right direction.

I was aware of my natural disposition to being a manager. I cared about people and was communicative by nature. But I knew I had to cultivate my gift and was absorbing all the management books I would stumble across. After reading 15 or 20 of them, I felt I was well immersed in the subject that I should start applying what I learned. Keeping notes at all times and jotting down my ideas proved to be useful as I was able to get back and review them when needed.

Reading was not nearly enough, and I had to improve some of my technical skills, particularly those related to architecture. When I was working on new architecture solutions, I would be drawing some sketches for our new back office with a pen on paper. I also improved my skills to be able to create new databases single-handedly, including new plans and diagrams for the entire company.

I also introduced a number of new processes -- weekly management and product meetings, the system for collecting feedback, and minimizing tech debt, the handling of different types of requests, etc.

Finally, I had to do a lot of managing up and convince leadership that we need to invest enough time and effort to identify the right problems and then, after coming up with the first version of the solution, keep iterating following the feedback from our customers.

Lessons learned

• Many people before me experienced similar challenges, often not in the tech industry at all. Learning from their experience was invaluable. I believe that people can encounter a finite amount of problems when managing other people (unlike when working on ever-evolving software). Don’t be afraid to face these problems; experiencing them more would make you better at solving them.
• Try to stay technical and keep up with the latest trends. Share information with your peers and learn from other engineers. Don’t reinvent the wheel -- learn about things other people did before you, become familiar with technologies or methodologies they used, and apply them to your own work.
• Engineering is like running a marathon -- you shouldn’t rush, but you shouldn’t be too slow either. Keep a consistent pace. No one likes unknowns, unpredictable things, and emergencies. Try to reduce them by planning in advance and setting up processes that would anticipate them.
• I had to say more NOs than I thought I would. My new role made me the first person to be asked for any requests, change, favor, etc. While often uncomfortable, your NOs will make you feel much better long-term.