Why You, Lead Dev, Shouldn’t Architect That Project

I can completely understand the overwhelming feeling deep down inside your chest right now: You’re the big fish, the one with the nice shoes and the awesome haircut. You fought from the bottom of the barrel and are now at the top. You’ve gone through the trials and tribulations that all junior and senior developers before have, dealt with legacy codebases that made you want to scream, and architectures designed by novices and out of touch lead developers that just passed ideas down from their ivory towers. You have, through years of experience and weaseling your way up the ladder, earned the right to architect that shiny new project your client/boss has just thrown in your lap.

I understand the sentiment because I share it. I have even acted on those feelings and lorded over my kingdom with my grand, perfect architecture.

Six months later, when I no longer touched the codebase and members of my team were frantically trying to figure out how to make X fit in Y, I found myself constantly trying to justify and explain the decisions I had previously made.

The Problem is…me?

You see, that’s the problem. I only cared for the dream, not the reality. Many developers before me had fallen into that trap, whether they were juniors or leads, and many more will fall in after me. But most importantly, I forgot that I would not be building the product, only overseeing its delicate work. I was handing blueprints to a group of architects and telling them to build the same exact thing, but in a way that fit the actual client needs three months later.

Now, I will say that I’m good at architecting. Impressively good, if any potential recruiters or future interviewers out there are reading this. I have a ton of experience and knowledge that’s really hard to just stumble upon (though I managed, somehow) and I bring some unique perspectives to the table. I’m also a bit of a control freak, so when I decided to no longer personally architect a project, I needed a way to still have my fingers in the pie, without getting in the way. After all, as development managers, it’s our job to help guide, help nurture, and help ensure project quality.

My plan? Well, here’s how architecting should go down:

  1. When a project has been scoped and passed along, or new features are going to be added to an existing project, you pull in the whole team involved in that project and give them a run-down of features and any future tasks that may or may not run through the door.
  2. You task the team with creating the architecture and solution for the feature sets coming through the door. Brand new projects are more extensive, add-ons to existing products tend to be less extensive, unless some kind of major overhaul is needed due to major project scope changes.
  3. You give the team a set amount of time to plan, where you invite them to ask you questions, but generally just leave them alone and stay away from them. You don’t want your presence to throw any brain-sun on brainstorming.
  4. After gathering their ideas, you have them pitch the idea to you. The goal is for them to articulate clearly why their architecture and solution, the reason they went with that architecture and solution, and how their architecture and solution is potentially future-proofing the project.
  5. You give them some constructive criticism, usually just in the form of questions. If you’re a manager and haven’t mastered the art of constructive criticism, go read some articles and grab a book about it. It’s important.
  6. They respond, you all collaborate to patch any holes in their proposal, and then you all figure out what steps need to be taken to implement the proposal. After all, it’s important to keep an architecture within scope and estimations.
  7. They build it. You go drink some coffee, tea, or beer and high-five a project manager.

Benefits Outweigh the Risks

You’re still concerned. I get it, I get it. But at this point, even with no code typed towards a project, you’ve gained an intangible benefit: your team now feels empowered. They’re probably excited for the project. After all, what dev doesn’t like to start from scratch? I’ve written an article about team empowerment before, but it’s worth repeating: empower your employees, save yourself a series of painful headaches.

Of course, that’s not all! If you order today, on top of the empowerment, you will also have:

  • Taught and enabled less experienced, or less management-driven developers, how to effectively architect a project.
  • Nurtured a team atmosphere full of collaboration.
  • Established early architecture documentation. For real, have your team write everything down and throw it in a README.md or wiki. Please. For you, for them, for me.
  • Kept your own ego out of the architecture process, and helped keep the project more maintainable by spreading base knowledge about the project across the entire team.
  • Made the world a better place for the potential next lead developer who has to take over the project. At least you know the next lead won’t be aching to take a little leak on your grave!
  • Most importantly, crafted a better architecture. More than one brain is usually better than one brain.

You’ll Always Be a Snowflake

So just accept it. You are super special, but so is your team. Let them make their own architectural decisions and act as a guide, not a dictator. You’ve earned it.

Show your support

Clapping shows how much you appreciated Mike Mclaren’s story.