Tips to Foster Pragmatism on Your Engineering Teams & Managers
In the fast-paced world of engineering leadership, the ability to balance pragmatism and idealism is a crucial skill that distinguishes good engineers and managers, to exceptional ones.
From understanding the nuances of pragmatic decision-making to coaching your team on foundational principles, this article provides practical strategies and questions to ask yourself that have proved useful to enhance an engineering team's effectiveness.
Before we dive in…
Your Degree of Pragmatism or Idealism Shapes Your Decisions. Picture it as a spectrum oscillating between extreme idealism ("nothing goes out until it's perfect"), and extreme pragmatism ("we released something quickly and it somewhat works, what more do you want?"). It’s worth keeping in mind that your personal stance on this will impact your view - and recognizing your
Defining Pragmatism in Software Engineering and Engineering Management
First, let's start with one important truth: There is no one "true," "right," or "ideal" way to build software. As an industry, we're constantly learning about what works. And as companies, we constantly learn and evolve what works for us to help us achieve our goals.
Pragmatic engineering means that what engineers deliver has an impact on the business.
It means using:
the right technology solution
at the right time
at the right cost
to solve the problem at hand
The same applies in engineering management: Reflecting on my journey, I used to be a strong idealist in leadership and management practices within organizations. I'd create lengthy documents with proposals for organizational changes, considering all details, caveats, while aiming for an optimal solution. Unfortunately, more often than not, a lot of those proposals never became reality.
Similarly, when I'd discuss proposals from other cross-departmental leaders, like an HR/people team, I'd get so into the details and inadvertently push their proposal to what I considered the best possible thing we could do. As a result, the stakeholders I worked with became frustrated.
Based on this short list alone, you can already see that there are a lot of factors to pragmatism, which can make finding a pragmatic approach quite tricky sometimes!
After almost 20 years in the workplace, I do still have some idealism in me - in the sense that I still hold myself and my organizations to high standards and values. At the same time, I've learned to balance high standards with a pragmatic lens focused on quick, impactful changes.
The lens I use to create change now is usually focused on:
What can we make happen quickly within the constraints we're dealing with?
How can we iterate on the initial solution to improve it over time?
What can we do to change the system and constraints in the long term?
I do still believe in creating better organizational systems. I also found that small solutions, implemented quickly, can be a great way to unlock changes and get out of a standstill, and buy trust for bigger approaches later.
How Can You Help Your Team Become More Pragmatic?
No matter if you want to help an entire team become more pragmatic or work with an individual engineer or leader, here are steps you can take:
Coach them on the foundations
Pragmatism's foundations lie in aligning solutions with business impact, understanding economic implications, conservatively planning capacity, and fostering a culture that values efficient outcomes over perfection. The more you can instill this formula with your team, and adopt and be an example of pragmatism for your team, the quicker you’ll see change.
Discuss business needs, goals, and priorities
Talk about business needs and goals with them regularly, and make this a recurring discussion point in your meetings.
My favorite and most effective discussion topics include:
What's our strategy?
What's our main goal?
What are our priorities as a business?
Make sure to connect to the employee's area of work: What does this mean for the priorities of your team/domain/department?
You can find more recurring discussion topics like these in my popular article about strategic leadership, where you can also download a cheat sheet.
Understand the business’s economics
I've been in many discussions with engineers that proposed huge technical projects spanning several quarters, and had to explain why those are not feasible, or at least not feasible this way. Especially in companies where money wasn't a concern for the last decade, many people never had to learn to think about the economics of projects.
Guide your team to consider the economic aspects of their projects. When you're discussing project ideas or other investments, ask them to think about:
What does the team cost per week?
What does this project cost, in hours and currency?
What are the risks associated with taking on this work (e.g. binding development capacity for a long time)?
What opportunity cost does it entail, i.e. what can we not do if we're tackling this work?
Can we afford this investment? Do we want to pursue this over other opportunities?
Pro tip: If the engineer or manager you're working with doesn't have budget access, ask your HR or Finance team what number they use to calculate the employee cost per hour. Most organizations have this number, and you can use it to make calculations yourself, and share it with your team.
Be conservative with capacity
Teams are often quite optimistic during planning, and don't always have a good sense of forecasting real outputs. A big part of planning is knowing how good a team is at estimating how much they'll be able to get done.
Helpful metrics are:
Goal accomplishment over the last quarter(s) or year
Planned vs. done work
How is the team’s ability to plan changing over time? This can be measured in one or both of these metrics over time. - Ideally, as a team understands its systems better and gains more knowledge, and their ability to plan improves, they should get better at estimating their capacity and planning.
Other metrics that are interesting for understanding a team's capacity limits:
Investment distribution flowchart, showing how the team's work is split between features/forward-facing work, technical debt, maintenance, defects, and escalations.
Ratio of new to resolved defects (divide new by resolved, if the number is 1 or greater, it points to the team not being able to keep up with addressing bugs)
Review these metrics with your team during planning or retrospective meetings. Overall, looking at these regularly will help convey that:
Capacity is limited,
A part of the team's capacity is usually already planned for, e.g., by bugs or customer issues that need to be addressed.
Therefore, we need to carefully consider what we're prioritizing for the team to work on.
Know that "perfect" isn't the point
Getting things done is more important than getting things done perfectly.
There are exceptions to this rule, of course. There are cases where perfection is absolutely required; those are very rare and if that's the case in your team, you likely won't read this article. For instance, I've led teams that had to deliver to an exceptionally high standard of work because we built software that could have threatened people's health if we weren't delivering stellar work. Security and data accuracy were aspects that we couldn’t compromise on.
However, even in those cases, we had to work quickly. This meant that we actually used a high degree of pragmatism in how we did our work. We used robust and well-tested approaches combined with perfectionism when it came to the results by not compromising on essentials and reviewing our work closely before pushing it out. That's an important distinction.
Getting things done and getting a good outcome is what matters. This doesn't mean you should be sloppy or careless in your work - it just means that you do things in the way that helps you get things done and achieve those outcomes, instead of focusing on the perfect way of doing things.
Create a landing spot for big ideas
Yes, pragmatism and small, quickly doable approaches are important. But while we help people become more pragmatic, I also find it critical to make sure that we still make space for the big, grandiose ideas and don't just shut them down. After all, just because something isn't feasible now, doesn't mean it never will be. It helps people stay motivated when they know that they can still think big, and their big ideas get acknowledgement.
One very practical way to do this? Create a landing spot for bigger ideas and initiatives. This can be a simple shared document, a wiki page, or an idea backlog. Just make sure that everyone in your team(s) can edit it, and agree with everyone on how often you review it. I found agreeing to review ours twice a year during strategic planning sessions was the most effective.
Questions to ask to increase pragmatism
What problem are we trying to solve?
What's a good enough version of this that we can launch quickly?
What function/functionality will this first version entail?
What enhancements can we do after the launch?
Is the proposal we're reviewing
the right technology solution
at the right time
at the right cost
to solve the problem at hand?
Lastly, keep in mind:
Pragmatism comes with experience.
I often see a high degree of idealism and "strong opinions, strongly held" in people who are either very early in their career, have worked at the same company for a very long time, have only worked at one or two different companies so far, or have worked in very similar environments. The reality is: There is no perfect business, and there's no perfect way of doing things that applies to all.
There are useful frameworks, tools, and approaches for getting things done, but those only work when we apply them to where our organization is now, and to where we want to go. Working in various environments helps us understand different complexities, and develop the pragmatism to get things done in ways that are likely not perfect, but that get the job done.
Pragmatism is about focusing on what matters
To instill pragmatism within your team, coaching on foundational principles becomes pivotal. Aligning solutions with business impact, understanding economic implications, and fostering a culture valuing efficient outcomes over perfection lay the groundwork for success.
Regular conversations about business needs, goals, and priorities, coupled with an understanding of the business's economics, guide teams toward effective decision-making.
Being conservative with capacity planning and embracing the imperfection of "good enough and launched" over "almost perfect but still not done" reinforces the pragmatism mindset. While exceptions exist where perfection is imperative, the key lies in achieving outcomes efficiently rather than fixating on an idealized process.
