I’ve been having conversations at SEP about how to evaluate software project opportunities for our firm.
We can talk about things like the what the project is, whether or not we think the client will be good to work with, or the size and budget of the company. These are all useful criteria when talking about during strategic sales discussions.
But something that I specifically have been asked to help with is how to determine if engineers would find the project enjoyable. Would it be fun to work on?
I think there are a few levels of thinking required to answer this question, each more refined and nuanced.
Level 0: No opinion
Early in your career you’re still figuring out how to build software, how to work on a team, and generally finding your footing. You might not have much preference about what you work on. In an optimistic case, you’re happy to work on anything! It’s all new and exciting. In a pessimistic case, you have no frame of reference for what an enjoyable and enriching project should feel like so you can’t identify red flags.
Level 1: Surface level attributes
After a while you start to form opinions and preferences on the type of work you like. This manifests with statements like “I love coding in Ruby” or “I don’t like embedded development” or “My ideal project would be building software for spaceships”.
These kind of attributes are easy to spot when assessing an opportunity. Most briefings will include the domain, tech stack, or other details that allow an engineer to judge the project based on their own interests: this would “check the boxes” for me because it’s a .NET web app with Angular.
We can build a list of keywords that less technical folks can look for. We can kill opportunities that match some kind of ‘blacklist’ and elevate ones that perk up our ears.
Level 2: Foundational attributes
Eventually, you’ll have the opportunity to work on a project with good surface level attributes. Unfortunately, you might find that despite checking the boxes, the project was not fun or enjoyable.
You might work with an amazing spaceship startup and a cutting edge tech stack, but find that you are constantly blocked by external dependencies, expected to work overtime, and not given authority for important decisions that impact your team.
This an extreme. But I have found that when I look back on my own career, there were projects that looked awesome on paper and turned out to be not so great (and vice-versa). Deep down we know this to be true; often how we feel about a project has little to do with the specific technology we are working with.
The foundational attributes of project enjoyment are deeper and more difficult to evaluate. We can try applying mental models like Daniel Pink’s motivation trio of autonomy, mastery, and purpose.
Autonomy
- Will we be able to make our own choices on tooling, techniques, and practices?
- How much do we ‘own’ the success of the project? How much are we depending on things or people outside of our control to make progress?
- How will work be planned, budgeted, and distributed among the team(s)? What influence do we have in the direction of the project?
- Is the client bringing a “problem to be solved” or a “spec to be implemented”?
Mastery
- Will we have the opportunity to gain expertise in a modern/desirable tech stack?
- What new skills will we be able to practice? What kind of knowledge can we acquire?
- What sort of leadership opportunities will be available for the team? Can this project support a person new to leadership getting some reps?
- Do we have sufficient foundational knowledge to execute the project on a technical level?
Purpose
- Who are the end users? Internal employees? Other developers? Customers? No one?
- Can we understand and empathize with the domain? Is there sufficient interest to dive deep and live in the client’s world?
- Are we aligned on the practices and values that matter?
- Are we making this small corner of the software world a better place?
When assessing project opportunities we are working with incomplete information. It is certainly easy to weigh only the surface level attributes of a project; it’s easy to explain, it’s easy to filter, and it’s easy to pattern match.
But the trouble is that most of these attributes are superficial. We know that two projects with an identical tech stack or for the same client will have differences in how fulfilling and enjoyable they are. In some cases, the difference is huge!
It’s hard to go beneath the surface. Some of these attributes take years of experience to uncover; there is a lot of trial and error and introspection involved. And even once we’ve found a satisfactory list of questions, most of them are tricky to answer. They are less “yes or no” and more “well, maybe, it depends”.
I won’t assume that I’ve found the ideal model yet, but digging deeper into what actually makes for a “good” project is a worthwhile exercise. For my SEP, our average project duration and sales pipeline means that our evaluations of project opportunities right now will impact the work we’ll be doing over the next 3-5 years. I’m hard-pressed to think of a higher leverage activity to be thinking about and trying to improve.
