#OpenToWork answers the question: who will hire me?
#OpenToFork asks a different question: what can we build together?
There is an unusual paradox in the labor market.
At any given moment, there may be a large number of highly capable professionals who are between jobs, contracts, or projects, while companies simultaneously claim that they struggle to find the right people, complete teams, or combinations of skills required to build a particular product.
The problem, then, is not always a lack of capacity.
Sometimes the problem is that this capacity is dispersed.
One person has twenty years of domain experience. Another understands product. A third can build it. A fourth knows how to sell it. A fifth understands the market in which that product would need to exist.
Viewed separately, they are candidates.
Connected around a specific problem and actual work, they can become a team.
This is where the idea of #OpenToFork begins.
Open to Work Is a Signal of Availability
LinkedIn's #OpenToWork has a very clear function.
A professional signals to the market: I am available. I am looking for my next opportunity.
That makes sense, and Open to Fork is not intended to replace it.
The Open to Work model assumes that the next step comes from the outside.
A company has to define a need, open a position, find a candidate, run a selection process, and hire them. Until that happens, a person who has knowledge, experience, and available time largely remains in a state of waiting.
Their employment status has changed. Their professional capacity has not.
So another question can be asked:
What if people who are Open to Work were also Open to Fork?
You Are Not an Empty Repo Just Because You Are Between Jobs
In software development, a fork does not come from nothing.
Something of value already exists: code, structure, an idea, previous work. A fork allows a new direction to be developed from that existing foundation.
The same logic can be applied to people.
A professional who has lost a job is not an empty repository.
They carry previous projects, knowledge, ways of thinking, contacts, experience with problems that have already been solved - but also experience with solutions that did not work.
For senior professionals, that accumulated capital is often considerably more valuable than their current job title.
Open to Fork would signal that this capacity is available not only to a future employer, but also to other professionals with whom it can be combined.
Not so they can wait for work together, but so they can build something together.
This Is Not an Entirely Theoretical Idea
The principle behind Open to Fork is not new to me.
We used a similar approach when developing DVeb DESTE/FDESTE teams.
We did not always start with a ready-made team that already existed in the market and simply needed an engagement. We connected individuals with complementary capabilities through actual work and gradually developed them into a functional delivery unit.
There is an important distinction between a group of people and a team:
A group may have all the required competencies on paper.
A team has to prove that it can coordinate work, share responsibility, make decisions, solve problems, and deliver continuously.
You do not establish that through CVs. You establish it through work.
Some of the people who were connected in this way are no longer individuals gathered around a single engagement. Today, they operate as one team and are employed by their own DESTE.
That experience matters more to me than the theoretical premise behind the Open to Fork concept.
It showed that a team does not always have to exist before it gets an opportunity. Sometimes a team emerges because the right people were given a reason to work together.
Open to Fork attempts to move that process one step further upstream.
From a Market of Candidates to a Market of Potential Teams
The traditional labor market primarily looks at individuals:
- Frontend developer
- Product manager
- UX designer
- Sales executive
- Business analyst
- Domain expert
Each person has a profile, a CV, and an availability status. But most serious products are not the result of a single competency.
The more interesting question, therefore, is what happens when available individual capacity is viewed as a set of potential combinations.
For example:
- someone understands a problem in the insurance industry;
- someone knows how to model the product;
- someone can design the technical architecture;
- someone can implement the MVP;
- someone understands distribution and sales.
None of them, individually, may have sufficient reason to start a project. Together, the five of them might.
Open to Fork could therefore operate as a very simple pre-team formation layer:
individuals >> problem >> collaboration >> delivery >> team
Not every attempt has to complete the entire path. The point is that the path exists.
What Exactly Gets Forked?
There does not have to be an existing GitHub repository to fork. That is not what I am talking about exclusively. It is a metaphor.
The object of collaboration might be:
- a specific problem,
- an idea,
- an existing prototype,
- an unfinished product,
- an open-source project,
- research,
- a methodology,
- an internal tool worth rethinking,
- domain knowledge that has not yet been turned into a product.
One professional might say: I know a problem this industry has been solving poorly for years.
Another: I can build the technical solution.
A third: I know how we can test whether there is a market for it.
That is already enough for the first fork.
The First Outcome Does Not Have to Be a Startup
Open to Fork should not be turned into yet another startup idea factory.
That would be the wrong measure of success.
The first objective should be considerably simpler:
Can a group of people who were not previously a team produce a defined result together?
For example:
- four people,
- four or six weeks,
- one problem,
- a clearly limited scope,
- one demonstrable outcome.
The result might be a prototype. It might be an open-source package. It might be research demonstrating that the idea does not make sense. It might be a product worth continuing. It might even lead to a new company.
But it could also produce something of more immediate value: a team that has just proved it can work together.
For the labor market and for a potential client, that is a fundamentally different signal from five separate CVs.
Delivery Is the Test
The most interesting part of the Open to Fork concept is not the idea itself.
It is delivery.
Four people can look like an ideal combination on LinkedIn. Only when they try to build something together do the real questions become visible:
- Who takes ownership?
- How is scope defined?
- Who makes the decision when there is no agreement?
- How are dependencies between different parts of the system handled?
- How is quality verified?
- How does the team respond when an initial assumption turns out to be wrong?
- Who finishes what was started?
These are the same questions that determine the quality of real delivery teams.
That is why Open to Fork can create value even when a project never becomes a commercial product, because it produces evidence of collaboration.
But This Is Not a Source of Free Labor for Companies
This boundary has to be established from the beginning.
#OpenToFork is not a program for providing companies with free labor.
A company that has a business problem, defines the requirement, expects a result, and retains the economic value of that result has a project.
For that project, it engages people and pays for their work.
Being unemployed does not amount to a 100% discount.
Open to Fork makes sense when people independently decide to invest their time together in something whose outcome belongs to them, or when they knowingly contribute to an open-source project under rules that are clear in advance.
A serious fork therefore needs to answer several uncomfortable but necessary questions early:
- Who owns what?
- What contribution is expected from each participant?
- How are decisions made?
- What happens when someone leaves the project?
- Who may later use the resulting code, design, or documentation?
- What happens if the project starts generating revenue?
Enthusiasm is not a substitute for governance. Especially not when a project becomes successful.
What Does the Professional Gain?
I would not promise employment, nor should that be the purpose of the concept.
What a professional gains is the possibility of ensuring that the period between two formal engagements does not become merely a period spent searching for the next one.
It can produce:
- a commit history,
- a working prototype,
- an architectural decision,
- market research,
- a validated problem,
- a new professional relationship,
- a team,
- a product.
In other words, it creates a new track record of work.
This is particularly relevant for people with extensive professional experience. Someone who has worked for twenty or thirty years may no longer have their greatest professional capital in their most recent job title. Their capital may lie in the problems they know how to recognize, the people they know, the situations they have already encountered, and their ability to see much earlier than others what is likely to go wrong.
Open to Fork allows that capital to be combined with the capital of other people.
What Does a Decision-Maker Gain?
For a CEO, CTO, or another decision-maker, there is another potentially interesting consequence.
A traditional hiring process attempts to predict a candidate's future behavior on the basis of their past.
An Open to Fork project can show their behavior in the present.
Not only: Where did this person work?
But:
- What did they build when nobody had defined their position in advance?
- Did they identify a problem?
- Could they work with people they had not worked with before?
- Did they take responsibility?
- Could they constrain the scope?
- Did they deliver?
And if several people do that together, the company is no longer looking only at individual candidates.
It is looking at a team with demonstrated experience of working together.
That is precisely the kind of experience that proved important in our case when developing the DESTE/FDESTE approach.
Minimal Implementation
Testing the concept does not require a new platform.
- It does not require a matching algorithm.
- It does not require another social network.
- At the beginning, a standardized signal is enough.
At the individual level:
#OpenToFork I bring: competencies, experience, domain knowledge. Interested in: problems or areas I would be interested in working on. Availability: the amount of time I can realistically commit. Looking for: the capabilities that are missing.
At the project level:
Problem - What are we trying to solve? Current state - Is there an idea, research, existing code, or a prototype? Needed - Who or what is missing? First delivery - What specifically do we want to have at the end of the first cycle? Time box - How long will the attempt run? Ownership - Under what rules does the resulting work belong to the participants?
If this model does not produce collaboration, there is no reason to build infrastructure around it.
If it does, the infrastructure can emerge from a real workflow rather than from assumptions.
Open to Work + Open to Fork
Open to Fork does not require a choice between looking for employment and creating something new.
A person can be both.
#OpenToWork tells companies:
I am available for my next engagement.
#OpenToFork tells other professionals:
I have available capacity. If we have complementary capabilities and a problem worth solving, we can build something together.
One model attempts to connect a person with an existing organization. The other attempts to find out whether several currently unconnected professionals can form a new delivery capability.
Based on my experience with DESTE/FDESTE teams, it is this second process that I find particularly interesting. I have already seen what can happen when individuals stop being merely individuals.
They can become a team.
And sometimes that team continues to exist long after the project that originally brought them together has ended.
Originally published by Dejan S. Višekruna on LinkedIn.
Top comments (0)