I'll save you some time. There's four ways, in order:
1. write an open source side-project
2. start a company
3. join a startup as one of the first employees
4. become the best employee and prove yourself over the years at some corporation, and they might let you participate when/if a green new project comes up
I was going to say design services. Nearly every project I do is greenfield. Of course there are constraints, but its all new code just about every time.
6. Work at a small or medium company for a year or two, and propose something better that will save the business time & money. That's how I've gotten all my greenfield projects (there's been many!)
Same here. I work for a big slow corporation but we’re a team of 2 and I’m the only one who codes and what the guy that left built was outdated the moment he started, now we’re getting ready to move to the cloud and nothing is compatible, so complete rewrite.
It’s a combo of proactivity , risk taking, skill set and reputation.
I’m on my 6th greenfield project across different orgs at a FAANG: one wildly successful, some moderate, and others product-market-fit failures.
In first joining, I was tasked with adding to an existing system, but befriended some Data Scientists on the side and started helping them automating their work, unofficially 20%. This spun out into a full on project that got VP backing.
That set my reputation for executing zero-to-one projects, and has stuck since.
It’s a high variance approach, since promo is tied to impact, and it’s borderline impossible to execute greenfield projects that ALL get product market fit. Some folks can’t stomach that kinda of career variance.
3. Technically true but it's not always what you want. A lot of startups are often doing rather simple technical work. My last job at an early stage was just writing CRUD routes for form intake. Gets old quick. Just FYI for anyone searching.
4 is true at a stagnant/steady-state company, but a growing company needs lots of new stuff created, and people with a bit of initiative can create and own domains far beyond what their titles or years of experience suggest they ought to be entrusted with.
Being in a context where doing big important new stuff is a positive-sum game can make a huge difference to a career.
Started working at a new company from March this year and finished one greenfield project already and working on my second one (due to be released maybe by January).
While also doing some bug fixes and new features for an existing product.
The company owners are very easy in this regard. If there's a new greenfield project upcoming, you can just express your interest and then start working on it. I guess the second greenfield project kind of originated from the first greenfield project I worked on. Owner figured out one feature of the project could be nice to sell as a separate library, if we can extend and improve its functionality.
I’ve effectively worked on greenfield projects my entire time at Amazon:
1. New service within Prime to handle GDPR and other compliance related matters
2. Opensource CLI tooling
3. New AWS service
4. Another new AWS service
Maybe (1) doesn’t count since it had to operate within a preexisting microservice ecosystem, but in the rest we’ve had complete control of the product from languages to servers to cloud infrastructure.
I’d wager there are always new teams in most large companies that are doing greenfield projects, you just have to look for them and be willing to join.
Is a greenfield project at Amazon actually greenfield the way anyone means though?
I assume there are org-wide style guides, best practices, approved languages and libraries, strategies, norms, etc. - I don't mean to say it's a bad thing (or make any judgement) but I'd have thought there would be relatively little difference from anything brownfield; that it's really just a 'not a monorepo' technicality?
I'm running a greenfield project at bigcorp, and I can tell you hands down "yes it makes a difference". Sure, you have to write it in the company language, do accessibility etc., but it's far better than being tied down to the last guy's hacks and assumptions, or cross team dependencies that can't be untangled.
As a freelancer I've been working on greenfield projects for last 3 years, all startup companies (3 of them). Has it's pros and cons. Projects sometimes fail, especially at this time one of my clients has financial difficulties, after spending millions on the app (team of 15 people).
Totally agree with the article…tutorials and courses tend to make it seem like a lot of “the job” will be spinning up a user model, when in fact most of it is trying to figure out why some piece of code is failing when it looks like nothing has changed.
I just got hired on for a greenfield project. It's a little different since it's in the contracting space. I contacted some colleagues from a previous company who were all working at the same company, told them what I wanted to do and basically wrote my own job description.
I'm taking project-ware and extracting customer specific requirements and code and making things built for a specific contract more generalizable and configurable.
Using a lot of things experience from two decades of contract work building the baseline config systems, data quality tools and subsystems that will allow project teams to use our of the box components to do implementation work with what amounts to code Legos. This is a very specific domain which is what makes any of this possible but it's a lot of fun. We're basically turning our contract group into a branded solutions group.
It's a neat intersection of product and project that I have not found much literature or past work on and decided to build it myself.
The vast majority of work I’ve done at startups of all sizes has been greenfield. The key is not looking at projects as “getting” them, but as recognizing a need, sketching out something that fulfills those needs, and rallying buy-in for that project that began with you, not some manager who is removed from the on-the-ground need.
The other key is being in a niche that gets fewer resources and being one of the early hires for the team not necessarily the org (which also helps).
24 comments
[ 7.9 ms ] story [ 86.9 ms ] thread1. write an open source side-project
2. start a company
3. join a startup as one of the first employees
4. become the best employee and prove yourself over the years at some corporation, and they might let you participate when/if a green new project comes up
It’s a combo of proactivity , risk taking, skill set and reputation.
I’m on my 6th greenfield project across different orgs at a FAANG: one wildly successful, some moderate, and others product-market-fit failures.
In first joining, I was tasked with adding to an existing system, but befriended some Data Scientists on the side and started helping them automating their work, unofficially 20%. This spun out into a full on project that got VP backing.
That set my reputation for executing zero-to-one projects, and has stuck since.
It’s a high variance approach, since promo is tied to impact, and it’s borderline impossible to execute greenfield projects that ALL get product market fit. Some folks can’t stomach that kinda of career variance.
Modularity, scalability, separation of concerns etc are your fig leaves.
PS: Have a cool name ready. Rather already start it calling that even before it is commissioned.
Being in a context where doing big important new stuff is a positive-sum game can make a huge difference to a career.
While also doing some bug fixes and new features for an existing product.
The company owners are very easy in this regard. If there's a new greenfield project upcoming, you can just express your interest and then start working on it. I guess the second greenfield project kind of originated from the first greenfield project I worked on. Owner figured out one feature of the project could be nice to sell as a separate library, if we can extend and improve its functionality.
1. New service within Prime to handle GDPR and other compliance related matters
2. Opensource CLI tooling
3. New AWS service
4. Another new AWS service
Maybe (1) doesn’t count since it had to operate within a preexisting microservice ecosystem, but in the rest we’ve had complete control of the product from languages to servers to cloud infrastructure.
I’d wager there are always new teams in most large companies that are doing greenfield projects, you just have to look for them and be willing to join.
I assume there are org-wide style guides, best practices, approved languages and libraries, strategies, norms, etc. - I don't mean to say it's a bad thing (or make any judgement) but I'd have thought there would be relatively little difference from anything brownfield; that it's really just a 'not a monorepo' technicality?
Greenfield at smaller companies has more technical decisions to be made, since as you say, FAANG already has strongly preferred frameworks.
It's a shame, since making technical decisions is an important source of professional growth.
I just never finish them
(it's what you were going to get anyways)
I'm taking project-ware and extracting customer specific requirements and code and making things built for a specific contract more generalizable and configurable.
Using a lot of things experience from two decades of contract work building the baseline config systems, data quality tools and subsystems that will allow project teams to use our of the box components to do implementation work with what amounts to code Legos. This is a very specific domain which is what makes any of this possible but it's a lot of fun. We're basically turning our contract group into a branded solutions group.
It's a neat intersection of product and project that I have not found much literature or past work on and decided to build it myself.
The other key is being in a niche that gets fewer resources and being one of the early hires for the team not necessarily the org (which also helps).