Greenfield Projects: Seven Ways to Set Yourself Up for Success
A developer’s perspective on building teams that build from scratch
There’s a story I once heard about a traveler and his party who peer out across an abandoned minefield to a site of buried treasure. There is no detour that will take them around it — they can cross together or separately, and they can go straight or around in circles. While they can deliberate over a plan, the sun is setting and they need to make a decision soon. What do they do?
That grassy field could represent opportunity — the path to success, riches, or adventure. Or it could be the opposite. A series of pitfalls disguised as freedom. Does this sound familiar? Does the term greenfield project ring any bells?
Serving customers by building something from the ground up can be an exciting opportunity. But the act of breaking ground can be risky. Depending on the company, the field you’re about to traipse across could be decades old, a mysterious wild with outdated superstitions about “peak process,” abandoned caves harboring systems that run Windows ME and that haven’t been updated since the late ’90s, and, oh yea, actual land mines.
But let’s not get too discouraged. After all, there’s potential for finding treasure. That’s why we’re all here. To build a great product and get it out into the market. A greenfield project is the opportunity to not only capitalize on an empty space in an ecosystem, but also to test our skill, our resolve, and our camaraderie. So what did the traveler in that story do? He reached into his pocket and pulled out a map.
What to Look Out For
There could be dangers waiting for you behind rocks and under soft patches of mud. Greenfield projects have a hidden set of needs — and each one can be an opportunity for growth if handled well! But if handled poorly or if not handled at all, these pitfalls can perpetuate and multiply across the lifetime of the project, taking you further and further away from your treasure and further into the endless cave of despair.
Check your pockets. Is your map ready to go?
- Without a goal, your efforts will be scattered
- A confusing domain model adds overhead everywhere
- Prefer collaboration, but in moderation
- Invest in your foundation, it supports everything
- Unpreparedness will cause frustrating delays
- Accept change
- A stable and reproducible development environment is a necessity, not a luxury
Without a goal, your efforts will be scattered
If you walk long enough, you will get somewhere. But without a clear vision of where you want to go, that place won’t always be what you were expecting. Defining a destination is key to making sure your greenfield gets from point A to point B instead of a tumble down the rabbit hole.
Having a goal the entire team can work towards means there are fewer chances to sink time and money into unnecessary work. It also empowers members of the team to make decisions on their own.
On the flip side, not having a clear focus means that the entire team’s efforts will be scattered. At best, it means you may let ambition get the best of you, and tackle too many things at once. At worst, it means that you may not actually accomplish anything. Neither point is something you want.
What we can do about it
It’s easy to ignore having a product defined from soup to nuts in the early days of a greenfield, simply because there is so much that no one can know. However, having some kind of goal in mind, even if it’s vague, will take advantage of every resource your team has, mental and otherwise, and focus it on one thing.
This goal can take more than one form — a milestone in Jira/Tracker, a document declaring what the MVP is, even a written statement. Having it will not only bring you closer to sharing what you’ve made with the rest of the world, it will also improve team morale (when you know what to ship, you know you can ship, and knowing that makes it easier to ship).
Of course, deciding on a guiding light is only possible when you understand the space you’re operating in. Which leads us to…
A confusing or non-existent domain model adds overhead everywhere
Business logic takes time to get onto the page and even more time to refine, and that’s assuming all of the knowledge about the business domain lives in just one head! In practice, domain knowledge is usually distributed across many people at the company, some of whom will belong to different departments. Depending on the timeline and organizational constraints, there isn’t always the institutional patience to establish a domain model early on. Corralling these people together, investing time into sketching out a domain model, and convincing these people that their time is not better-spent on the other tasks that are likely on their plates isn’t easy to do.
When the domain is not mapped correctly, everybody suffers. Product managers will not know how entities relate to each other. Developers won’t know how to implement those relationships. If the work starts without a clear picture of the entire system, errors will happen at the conceptual level. Imagine having to rewrite entire portions of code because an entity was mis-mapped or left out entirely! Fixing mistakes like this is time-consuming.
What we can do about it
I consider the initial domain modeling session to be an indispensable cross-team ceremony. Neither the developers nor the PMs on a project have an absolute grasp over the domain; one side, the former, understands how the relationships between domain entities in terms of structure, where the latter has more awareness of the business logic, and ultimately the customers, that are affected by the domain. A successful product needs both sides — Getting both together in a room is a great way to not only do the initial groundwork that the rest of the project will depend on, but it’s a good way to build team camaraderie. Which brings me to…
Prefer collaboration, but in moderation
It’s dangerous to travel alone! The whole team should be in this together. But teams are really just collections of people — it’s the strength of the individual relationships that make or break the team culture. And it is simply a fact of life that people need time to acclimate and learn to work with one another. This isn’t something that happens instantly, overnight, or even in one week.
It’s tempting to think of policy, process, or even software as foundation, but the layer that supports all three of those is the people. Having everyone bought into the cadence and rhythm of the greenfield team is key in terms of harmony. Meetings will be more productive, code reviews smoother, and deliveries predictable if everyone can work together fluidly.
As far as team dynamics go, the amount a team communicates is, in my opinion, an indicator of how well they function and how well they can respond to changes (good and bad). If walls are hindering the amount your people can talk to each other, it might be difficult to ship a patch if something breaks in production.
What we can do about it
Building tight, positive feedback loops support strong interpersonal relationships between the different parts of your team. If teams are able to operate and work with each other easily, work will get shipped faster.
That being said, something to keep in mind is that there is such a thing as too much collaboration. If you’re sitting in meetings that feature members of every department, where only a handful of people are participating, collaboration could be a blocker for productivity. The last thing anyone wants is a 30+ person standup that takes the entire morning. So there is a balance to be struck here. Try to find it.
Now assuming you have found your team’s center of gravity, remember that people aren’t just about work, so teams shouldn’t be either. Go to happy hour with the whole crew if you can! If a few beers aren’t in line with what your company does, having team-wide retrospectives early and often can also build and encourage a psychologically safe environment where people can contribute ideas without fear of being ignored or ridiculed. That last part is important, because…
Invest in your foundation, it supports everything
Greenfield projects mean building something from nothing, which takes considerably more time and effort than building something from something else. It also might take some trial and error. It can be tough to convince the non-technical stakeholders in a project that a slow burn in the beginning of a project is normal, but that isn’t any reason to avoid the conversation. A slower velocity in the first few weeks can actually be a sign of productivity that signals stronger growth in the future.
Embracing this initial inertia is essential because what your team is building at this point in the cycle is the foundation of the house. It’s the bottom-most layer of the Jenga tower. If the foundation is cracked, the building won’t stand. Developers and PMs need to build the basics before any meaningful business value arrives, and that takes time. If this essential phase is glossed-over, things will go wrong at a deep level later in the project without warning. It could mean even more time invested in a project at the least opportune time.
As an aside, I do think that product managers, specifically, can play a key role in communicating the reasons for slowness to the business. Development is often opaque to non-technical stakeholders. Product, as a bridge between business and technology, often plays a trusted role in relaying time estimates to other business stakeholders. A developer arguing for a target time budget for foundational tasks will benefit immensely by having support and understanding from the product team.
What we can do about it
There are too many adages to include here about how great things take time and how Rome wasn’t built in a day, so I won’t belabor the point. Building from the ground up takes time and resources if what you build is meant to stick around. Invest early so you don’t have to spend later.
Also, have patience! Stories will take longer to ship in the beginning — this is just a fact of working on a greenfield project. Normal time estimates have additional costs. Think of them as “foundational costs”. It is best to budget for these. While they can be ignored, they can’t be avoided. The last thing you want is an unexpected visit from one of them.
Unpreparedness will cause frustrating delays
Are you ready to begin working? Really, are you?
Even if you are confident that your team is ready to ship work, you may still want to take a second look. It might be tempting to overlook clerical tasks like getting contracts signed and partners prepared for integration, but things like that can be significant blockers when work begins. If an upstream backend isn’t ready, the whole team will grind to a halt.
It’s natural to split tasks into chunks that can be done in parallel. Time is money, and people are protective over it. However, like with all tasks we’ve outlined so far, a time investment planned earlier is way better than an unplanned expense down the road. It’s easy to strike a blow to morale by preventing the team from shipping, especially if it could have been avoided.
What we can do about it
Make sure the team is ready to roll on day one. Unless you’ve done it before, don’t underestimate what it takes. Sign every working agreement with every partner before the project kicks off. Make sure every member of the team has all the permissions they need to contribute from day one. Slack, email accounts, VPN access, JIRA boards — these should be available when the lights click on. Also, make sure the right person is at the helm of the ship. Having the right person provide both ground-level tactics and high-level strategy is instrumental for making sure every moving piece is moving at the right speed and direction. It’s a delicate exercise, but it’s worth doing precisely for that reason. If it was easy, everyone would do it.
Accept change
Sometimes greenfield projects are only green within a larger organization. The business might expect integrations with teams whose technology is outdated. What’s more, is that the business might be reluctant to make updates to older technology, even if an update provides significant benefits in terms of productivity, flexibility, and security.
What we can do about it
I wish there was more that could be done here, but sometimes the solution is to roll with the team culture. I heard a story from a colleague once about a transition between two systems her team was working on. The newer system would’ve afforded more speed and flexibility, but other members of the company who had become used to the older system simply didn’t want to change. It can be disheartening to realize that even though some choices are clear winners, sometimes it isn’t worth the risk to team morale to debate points like this. Not all change is bad, and when we ignore it we do so at our own risk.
A stable and reproducible development environment is a necessity, not a luxury
This is a developer-specific issue, but one that cannot be overstated. The needs of developers aren’t always taken seriously and as a result, we learn to work around obstacles, sometimes to our own detriment.
This is a problem because if it is difficult to write and ship code, I suddenly have an overhead cost on time and mental resources that I may not even be aware of. Having a development environment that is invisible means I can ship code without thinking about how to ship code. The payoffs in terms of time are huge. And if that isn’t enough, if I can ship easier I will look forward to working every day.
What we can do about it
Having a strong, developer-oriented onboarding guide can cut out many of the bumps involved in getting a working development environment set up. This is often lumped into the standard onboarding documents but, in my opinion, it shouldn’t be. It is a separate concern in itself.
Along with the permissions mentioned above (slack, email, VPN, kanban board), make sure all of the devs have access to every repository they need, any continuous integration they’ll need to push code to, etc.
If it helps, think of this cost in terms of efficiency: the faster a team of coders can get up and running, the faster they can start shipping. An unstable development environment will only add to the general level of unpredictability. I should be able to reproduce any errors I see in production, and I should be able to push fixes easily. No one wants to debug a broken deployment on a Friday afternoon, much less be forced to do it without the proper tools.
Also, if you’re not using Git, you should be. Your devs will thank you.
Are there any observations you’ve made while working on a greenfield project? Let me know at prakash@carbonfive.com.
Thank you to Jen Skene, Grace Song, and Matt Sullivan for input on this post and to Erin Murphy for the illustration.
Interested in more software development tips & insights? Visit the development section on our blog!
