How to Plan A Project as A Principal Software Engineer: A Human-centered Approach

TL;DR

👑 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.

Principal engineer is about bringing engineering, business, and people 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.

Is It The Right 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.

What Does Success Look Like?

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.

How to Ship It ASAP?

"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.
measurable.

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.

What about KPI Analysis?

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.

Is Performance Monitoring in Place?

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:

Should I code as A Principal Software Engineer?

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.

My leadership coach introduced a model to me called Situational Leadership. I use it to think about my involvement in projects. It looks like this:

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:

Prototyping.
Hackathon.
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.

Final Thoughts

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.

References

Articles

Books

Tools

💬 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.

If you're interested in Unicode in Rust and JavaScript, I wrote an article "Indexing Strings in Rust and TypeScript: A Case Study of String". There we discussed how Rust and JavaScript handle strings with a classic algorithm.

Happy coding!

Daw-Chih Liou

Daw-Chih is a software engineer, UX advocate, and creator who is dedicated to Web engineering. His background in Human Centered Computing has led him to work with startups and public companies across North America, Asia, and Europe. He is passionate about meeting business trajectory with user journey and utilizing engineering architecture and performance monitoring to provide optimal user experience.