515 reads

A Principal Software Engineer's Guide to Planning Projects Painlessly

by Daw-Chih LiouMarch 11th, 2022

Too Long; Didn't Read

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

Companies Mentioned

featured image - A Principal Software Engineer's Guide to Planning Projects Painlessly

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.

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.

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 an 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, 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 the 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 documentation. 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 with 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 situation 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 sequences depending on your situation.

What’s important is that at the end of the planning, you have a clear idea of how to iterate through your assumptions and bring the project live to the users.