I wouldn’t necessarily focus on “retaining talent.” Instead, I’d build a system where losing talent won’t hurt you. (Although, you can usually avoid losing talent at inopportune times with some simple performance bonuses -- "Get me through to X point, and you get a bump.")
A project like this will require a variety of people. New builds, problematic builds, or maintenance projects all demand different skill sets -- and different personalities.
If you need someone to jump in and untangle a mess, the right person for the job will have a take-charge attitude. However, that same attitude might cause issues once the project is running smoothly.
If you want someone to get it done and build it right, that’s great. But that person might be bored to tears when you transition from an all-hands-on-deck build phase to a skeleton crew for maintenance.
If you need someone who can maintain the code, tirelessly clean it up, polish the rough edges, and fix bugs, chances are that person wouldn’t have been the right fit to kick off the project.
These are all oversimplifications, but you get the point.
So, build the system assuming you’re going to lose staff. Hire people who are productive and get things done. Ensure you have good documentation and a solid handover process in place. Make sure everyone on the team knows how to do builds and has a designated backup.
What I’ve seen work really well are small teams -- like an “agency within the company” model. I’ve done a lot of digital transformation projects over the years, mostly in eCommerce and mar-tech systems (all systems with many integration points).
The single biggest thing that dooms projects is bad requirements. For example, "Oh, I don’t know how XYZ system works, but I’ll be damned if I’m extending that old agency’s contract by another year, so we’re losing access to the data on Friday -- just do what you can!" (This actually happened on a past project, and we lost the entire Product Information Management (PIM) system, forcing us to manually redo a lot of data. Don’t be that guy.) Make sure your system is fully mapped out and that you understand how it works before replacing the team.
When building your team, start small, as others have suggested. A product owner (who can double as your UX designer in a pinch), a tech lead (who can double as your QA automation engineer) -- look for people who can wear multiple hats. Over time, the team can grow, but start with a small team and challenge them to impress you. Then, sit back and see if they do.
Give them plenty of leeway. Don’t burden them with a bunch of “this is how we do things” processes. Hire smart people, empower them to make changes and challenge you, and let them tell you what they need to be successful.
From experience, I can’t stress enough that bad requirements kill projects. Someone creates a totally BS PowerPoint, hands it to a dev, and says, “Build this!” Or some junior dev says, “Yeah, I don’t really understand, but we can do five years’ worth of effort in three months…” That’s a recipe for disaster. They panic, cut corners, and leave you worse off than where you started. No junior folks for mission-critical roles -- seriously.
Look for pragmatic, honest, and hardworking people. Anyone who isn’t comfortable telling you to “fuck off” when you deserve it shouldn’t be in a leadership role or on a mission-critical project. Look for people who strive for a deep understanding.
You’ll also need to give them the right tools. I’m constantly shocked when I show up at a company where the cheapest person on my team is billing $1,200 a day, yet the company wants to saddle everyone with five-year-old Dell laptops and no external monitors, mice, or keyboards. Or worse, they say, “Here’s our 12-year-old Jira instance, but you don’t have admin privileges…” or, “You can VPN in and use a remote desktop client that runs like it’s on a 56.6k modem!” (I’m trying not to be outrageous, but both of these are issues I’ve faced in the last year.)
As the stakeholder who will own this team, make sure all the other BS is cleared off their plate. Give them whatever equipment they want, give them the project management systems they prefer, and don’t try to shoehorn them into your existing setup. Provide them with all the admin privileges they need. Your job is to knock down all the barriers that slow them down.
So, look for a strong leader who’s willing to dig into the details and isn’t afraid of hard work. That should be your point person to start with. “I want you to move a mountain for me -- what do you need to get it done?”
A project like this will require a variety of people. New builds, problematic builds, or maintenance projects all demand different skill sets -- and different personalities.
If you need someone to jump in and untangle a mess, the right person for the job will have a take-charge attitude. However, that same attitude might cause issues once the project is running smoothly.
If you want someone to get it done and build it right, that’s great. But that person might be bored to tears when you transition from an all-hands-on-deck build phase to a skeleton crew for maintenance.
If you need someone who can maintain the code, tirelessly clean it up, polish the rough edges, and fix bugs, chances are that person wouldn’t have been the right fit to kick off the project.
These are all oversimplifications, but you get the point.
So, build the system assuming you’re going to lose staff. Hire people who are productive and get things done. Ensure you have good documentation and a solid handover process in place. Make sure everyone on the team knows how to do builds and has a designated backup.
What I’ve seen work really well are small teams -- like an “agency within the company” model. I’ve done a lot of digital transformation projects over the years, mostly in eCommerce and mar-tech systems (all systems with many integration points).
The single biggest thing that dooms projects is bad requirements. For example, "Oh, I don’t know how XYZ system works, but I’ll be damned if I’m extending that old agency’s contract by another year, so we’re losing access to the data on Friday -- just do what you can!" (This actually happened on a past project, and we lost the entire Product Information Management (PIM) system, forcing us to manually redo a lot of data. Don’t be that guy.) Make sure your system is fully mapped out and that you understand how it works before replacing the team.
When building your team, start small, as others have suggested. A product owner (who can double as your UX designer in a pinch), a tech lead (who can double as your QA automation engineer) -- look for people who can wear multiple hats. Over time, the team can grow, but start with a small team and challenge them to impress you. Then, sit back and see if they do.
Give them plenty of leeway. Don’t burden them with a bunch of “this is how we do things” processes. Hire smart people, empower them to make changes and challenge you, and let them tell you what they need to be successful.
From experience, I can’t stress enough that bad requirements kill projects. Someone creates a totally BS PowerPoint, hands it to a dev, and says, “Build this!” Or some junior dev says, “Yeah, I don’t really understand, but we can do five years’ worth of effort in three months…” That’s a recipe for disaster. They panic, cut corners, and leave you worse off than where you started. No junior folks for mission-critical roles -- seriously.
Look for pragmatic, honest, and hardworking people. Anyone who isn’t comfortable telling you to “fuck off” when you deserve it shouldn’t be in a leadership role or on a mission-critical project. Look for people who strive for a deep understanding.
You’ll also need to give them the right tools. I’m constantly shocked when I show up at a company where the cheapest person on my team is billing $1,200 a day, yet the company wants to saddle everyone with five-year-old Dell laptops and no external monitors, mice, or keyboards. Or worse, they say, “Here’s our 12-year-old Jira instance, but you don’t have admin privileges…” or, “You can VPN in and use a remote desktop client that runs like it’s on a 56.6k modem!” (I’m trying not to be outrageous, but both of these are issues I’ve faced in the last year.)
As the stakeholder who will own this team, make sure all the other BS is cleared off their plate. Give them whatever equipment they want, give them the project management systems they prefer, and don’t try to shoehorn them into your existing setup. Provide them with all the admin privileges they need. Your job is to knock down all the barriers that slow them down.
So, look for a strong leader who’s willing to dig into the details and isn’t afraid of hard work. That should be your point person to start with. “I want you to move a mountain for me -- what do you need to get it done?”
Happy to chat, my email is in my profile.