Take the Big Project
Something I’ve learned as an engineer: when presented with the option of working on a big project, or doing anything else, take the big project.
The Big Project™ is a new dashboard, an AR/VR/AI integration, an experimental mobile or hardware app, etc. They take multiple people days to plan, and at least a month to complete, possibly with multiple engineers. People on the team are excited (and possibly a bit intimidated) by the idea of being the lead on the Big Project.
Counterarguments
Let’s address the counterarguments right away. Yes, Big Projects are harder to pull off. Yes, there’s a chance you will fail.
I’m writing this blog post partially for me. I tried to avoid Big Projects early in my career because I was afraid I wouldn’t be able to figure them out. Then I got into consulting, where Big Projects are pretty much all you do. Finding my way through that, again and again, taught me that the risks of the Big Project are worth it.
Reasons To Take the Big Project
Here are a couple of reasons to take the Big Project.
You’ll learn more. There’s no faster path to improvement as an engineer than building things. You get to create. You get to get stuck, then unstuck, learning tons in the process. You get to take an amorphous idea and turn it into ones-and-zeros in production. You get to make choices and live with them. When it comes to learning, the Big Project is the fast lane.
You’ll gain ownership. Ever wonder how that founding engineer on your team became the “Email person” at your company? They stepped up and built the original email architecture from nothing. They may have never done such a thing before. Now they practically own the whole system. As long as you remain interested and engaged, it’s good to be that person. That person knows what’s going on and is very secure.
You’ll get to build patterns. Ever wonder why that set of utility functions in your codebase is a little bit ingenious, when it didn’t have to be? Somebody who kinda knew functional programming patterns could be used in your JavaScript (or whatever) built them. Big Projects require new things: new patterns, new test frameworks, new libraries, new solutions to new problems. When you take on the Big Project, you get a vote on these patterns.
You’ll have visibility. I like when my boss can tell their boss: “Jake is working on X”, instead of thinking “What is Jake doing?” and assigning me a one-point story. I like having that cover when busywork lands on the workbench. “I can’t assign Jake to audit our open-source license compliance; he’s building the RFID system.” It’s nice to build things that have unequivocal business value. It’s work that’s unlikely to get de-prioritized.
You won’t have to context switch as much. Context switching– working on one task and then shifting to another in a different context– can be really tough. When you take the Big Project, it’s your job to stay in one domain for a while. You have a built-in reason to stay in that domain.
I just took on a Big Project. Start throwing yourself in front of them, and let me know how it works out.