- 👑 Shipping is queen.
- 🔭 Visualize and define success early on.
- Don't forget to include performance monitoring and KPI analysis.
- 🎯 Principal engineer is a leadership role. Think about your involvement in the project.
This article is also available on
Feel free to read it on your favorite platform✨
For me, operating as a principal software engineer is all about bringing engineering, business, and people close together.
Usually you're one of the first technical representatives in the organization to hear about a project as a principal engineer, and you need to make an internal dialog to either pursue or discard it. There are many things to consider in terms of time budget, resources, stakeholder communication, and even your own involvement when it comes to planning.
So I want to share with you how I think about planning as a principal engineer and what are the important questions to ask in the planning phase of the project.
You'll hear about the project in different maturities depending on how your organization normally generates business ideas. It could range from a observation of a potential user need to "we need it in three months". Regardless, a simplified train of thought looks like this:
- Do or don't do?
- If "do", is it the right timing?
- What's the engineering complexity?
- How's the effort?
- Do we have the resources?
- Do or don't do?
There are many more factors. What I'm suggesting is simply:
Follow your gut😎
Usually you'll have an intuition, an excitement or an energetic feeling, to say yes to the project. To develop the intuition over time, there are a few exercises I find very useful to formulate my engineering opinion:
- Learn your industry and the competitive landscape.
- Learn your organization's strategy. (If you're like me not really knowing what "strategy" means in the business world, I highly recommend the book "Playing to Win: How Strategy Really Works" by A.G. Lafley and Roger L. Martin.)
- Align the project with organization's OKRs.
- Talk to the designers about the user needs and pain points in their research.
- Talk to the project managers(PM) or product owners(PO) about the market research.
- Visualize your organization's project portfolio. Just by looking at it, you'll get a better sense of the balance between short term and long term commitments, team/project allocation, and buffer for adaption.
If you are not sure about how to prioritize it, you can work on a Prioritization Matrix with your team to figure out where the project stands. A Prioritization Matrix looks like this:
Note that Voting based on expertise is critical in the process because it will reveal how people in different disciplines think about the importance and urgency of the projects. It's a invisible third axis of the matrix.
Visualizing what success looks like early on helps you in many ways:
- Solidify your gut feeling about the project.
- Communicate the goal and alignment with OKRs to others more clearly.
- Design KPIs to measure the progress and impact.
I like to use Amazon's "Working Backwards" approach to put my thoughts in a press release. It is a great way to put people in the same frame of mind just by "seeing" what happens after the finish line.
I use the press release as the starting point to invite conversations and consolidate the references to the documentations. Usually includes:
- Project epics or overview.
- UI Design mockups.
- Engineering system designs.
- KPI analytics.
"Ship to learn."
It became my guiding principle ever since I read about this quote. GitHub shares the same idea in their leadership principles and I think the mindset is the foundation of lean and agile software development because it's:
- human-centered and user-focused.
- powered by iterations of feedback and learning.
I like to use Design Thinking as a framework to think about the problems and how to iterate throughout the project. Combining with the press release and KPIs, it's a great way to validate your assumptions and stay in the course.
Design Sprint is another great tool to crack a problem and kick start the exploration. Most importantly, it's fun
When you're facing a complex project, make sure your system design proposals include alternatives that are simpler and quicker to build. It'll allow the teams to iterate faster.
The takeaway here is to really focus on delivering the project to the users' hands, instead of implementing a complete solution.
It's very useful to look at business KPIs and UX KPIs side by side to get a better sense of the data. It's important to dive into the analysis with PMs and designers to find out the direction of the next iteration.
There are a few basic concepts in statistics I learned that are useful to collaborate with Business Intelligence and Design teams.
- Permutation Testing
- A/B Testing
- A/B/n Testing
- Multivariate testing
- Multi-armed bandit
- When To Do Multivariate Tests Instead of A/B/n Tests
- The Multi-Armed Bandit Problem and Its Solutions
Technical performance is another opportunity to inject engineering context into discussions for the next iterations.
In general, there are two types of monitoring:
- Real User Monitoring (RUM)
- Synthetic Monitoring
RUM is about live data. It tells a story of real user behavior and how your system performs over time. Synthetic monitoring reports data of your system in a controlled environment so it's suitable for static analysis, regressions testing, and performance testing.
Here are some useful tools for monitoring:
I believe you should, but the bottom line is to empower engineers and make sure your involvement doesn't block or interfere the iterations.
Many principal engineers have different opinions and experiences but I truly believe that if coding is your craft and you love it, you should code. The question is more about when and where you should be coding.
The model suggests that there are 4 types of leadership styles and you can fluidly choose the styles to lead based on the situations.
For situations of supporting and coaching, I think the best place and time to code are:
- Tooling for developer experience.
- Data visualization.
Your intention is to maintain a certain level of involvement and visibility to the projects to provide support when needed. The situations happens usually in important projects with a longer time frame. They are also the type of projects that you spend time on mentoring and sponsoring engineers.
For situations of directing, I think it's better not to code because you're highly invested in the direction of the project. You'll be doing a lot of analyses and communications. Hands-on work often distracts you from your focus.
We touched on the questions I find useful in planning:
- Is it the right project?
- What does success look like?
- How to ship it ASAP?
- What about KPI analysis?
- Is performance monitoring in place?
- Should I code as a principal software engineer?
It's important to know that there's no specific order to these questions. You can think about them in different sequence depending on your situation.
What's important is that at the end of the planning, you have a clear idea how to iterate through your assumptions and bring the project live to the users.
- Amazon's Working Backwards approach - Quora
- Amazon's Working Backwards Press Release Template and Example - Ian McAllister
- Design Thinking 101 - Nielsen Norman Group
- Why Design Thinking Works - HBR
- Design thinking, explained - MIT
- The Design Sprint - GV
- How we use "ship small" to rapidly build new features at GitHub - Dev Community
- The Permutation Test: A Visual Explanation of Statistical Testing - Jared Wilber
- Multi-armed bandit - Optimizely
- The Multi-Armed Bandit Problem and Its Solutions - Lilian Weng
- A/B Testing - Optimizely
- A/B/n Testing -Optimizely
- Multivariate testing - Optimizely
- When To Do Multivariate Tests Instead of A/B/n Tests - CXL
- p-value - Wikipedia
- Situational leadership: 4 styles and qualities
- Real-time monitoring of Formula 1 telemetry data on Kubernetes with Grafana, Apache Kafka, and Strimzi - Paolo Patierno
- Set Goals with OKR - re:Work
- Using Prioritization Matrices to Inform UX Decisions - Nielsen Norman Group
- What are objectives and key results (OKRs)? - asana
- Objectives and Key Results (OKRs) - GitLab
- What metrics and KPIs do the experts use to measure UX effectiveness? - UserZoom
- Key Performance Indicators (KPIs) for Optimization
- Engineering Function Performance Indicators - GitLab
- Being Glue - Tanya Reilly
- What do Staff engineers actually do? - StaffEng
- Performance Monitoring: RUM vs synthetic monitoring - MDN
- Software performance testing - Wikipedia
- Performance Testing vs. Load Testing vs. Stress Testing - Blazemeter
- Everything You Need To Know About Stress Testing Your Software - DZone
- Regressions Testing - Wikipedia
- Static Program Analysis - Wikipedia
- From Frontend Developer to Principal Software Engineer - Daw-Chih Liou
- Time management - Wikipedia
- Staff Engineer: Leadership beyond the management track - Will Larson
- Playing to Win: How Strategy Really Works - A.G. Lafley, Roger L. Martin
- autocannon - GitHub
- Performance API - MDN
- Testing Library
- Google Lighthouse
- K6 - GitHub
💬 Comments on Reddit.
Here you have it! Thanks for reading through🙌
If you find it useful, please share this article to help more people in their engineering journey.
Feel free to connect with me on twitter!
If you're interested in shipping Static site with Next.js and MDX seamlessly, check out my latest article "Building Better Next.js Static Sites with MDX and Contentlayer".
In my previous article "From Frontend Developer to Principal Software Engineer", I shared 50+ books and online resources that helped me in my engineering journey.
If you're interested in implementing Binary Trees in Rust, my previous article "Binary Tree Insertion in Rust" shared my struggle when I was implementing a Binary Tree. It took me some time to have a grasp on Rust's ownership.