Building a company teaches you things that no amount of planning can fully prepare you for.
When we started Siteligent, we knew we wanted to build a product of our own. That sounds straightforward when you say it in one sentence, but actually building a product company from the ground up is a very different experience. There are countless decisions to make, most of them without a perfect answer, and many of those decisions are connected in ways you don’t see at the beginning.
One of the things that changed the most for us was how we thought about people.
At first, hiring seems relatively simple. You have a role that needs to be filled, you define the skills required for that role, and you look for someone who has those skills. Experience, technical ability and relevant knowledge obviously matter, and they still do. But as we spent more time building Siteligent, we realized that those things don’t tell the whole story, particularly when you’re building an early-stage product company.
The people who join a company at this stage don’t simply fill positions. They influence how the product is built, how decisions are made, how problems are approached and, eventually, what kind of company it becomes.
That’s what this article is about.
Not a hiring framework or a list of rules that we think every startup should follow. We don’t have everything figured out, and we’re still learning ourselves. These are some of the things building Siteligent has changed about the way we think about hiring, working with people and building a company.
We Didn’t Start With a Perfect Hiring Philosophy
Like most things in an early-stage company, our thinking evolved through experience.
It’s easy to assume that the best person for a startup is simply the person with the strongest skills for the job. If you’re hiring an engineer, you want someone who can build well. If you’re hiring for product, you want someone who understands product thinking. If you’re hiring for design, you want someone who can create a good user experience.
Those things are important. But there is a difference between being good at a discipline and being effective in an environment where the discipline itself doesn’t always stay neatly contained.
At Siteligent, the product is still evolving, the company is still evolving, and the way we work is still evolving. That means there are inevitably situations where a problem doesn’t belong neatly to one person or one function. A product decision can have technical implications. A technical decision can affect the user experience. Something that starts as a customer problem can turn into a product question.
In a larger organization, there may be a team for each of these things. In an early-stage company, the boundaries are much less clear.
That changed what we started looking for in people.
We became increasingly interested in how someone thinks when the answer isn’t obvious, how they approach something they haven’t done before, and whether they naturally look beyond the immediate task to understand the problem behind it.
A person can be extremely good at their specific job and still struggle in an environment where the job keeps changing around them. Someone else might have less experience but be exceptionally good at learning, asking the right questions and figuring things out.
For an early-stage company, that difference can matter a lot.
A Job Description Is a Starting Point, Not a Boundary
One of the realities of building a small product company is that responsibilities overlap. This doesn’t mean roles don’t matter. Clear ownership is important, and people need to know what they’re responsible for. But a job description can’t predict every problem a growing company will encounter.
There will always be things that aren’t clearly assigned to anyone.
A process might not be working. A customer problem might reveal something unexpected about the product. A feature might need to be reconsidered. Something might be technically possible but not actually make sense for the user. Sometimes there simply isn’t enough information to know what the right decision is.
Those situations are where ownership becomes visible.
We’ve come to think of ownership as something much broader than completing the work that was assigned to you. It’s about caring enough about the outcome to notice when something needs attention and doing something about it.
That could mean asking a question, investigating a problem, bringing an issue to the team’s attention, proposing a different approach, or simply taking the first step instead of waiting for somebody else to define it.
This is particularly important when a company is small. There aren’t many layers between a problem and the people who can solve it. Waiting for someone else to notice, assign and coordinate every issue can slow the entire company down.
The people who make the biggest difference are often the ones who don’t immediately ask, “Is this my responsibility?”
They first ask, “Does this need to be done?”
There’s an important distinction there. Ownership doesn’t mean everyone should do everything. It means people care about the outcome beyond the boundaries of their individual task list.
The Question We Started Asking Behind the Resume
A resume can tell you a lot about what someone has done. It can tell you where they’ve worked, what they’ve built, what technologies they’ve used and what responsibilities they’ve had.
But it doesn’t always tell you how they think.
And in an early-stage company, that can be one of the harder things to evaluate.
We started paying much more attention to questions such as: What does someone do when they don’t know the answer? How do they approach a problem that hasn’t been clearly defined? Do they ask questions that reveal genuine curiosity? Can they explain why they made a particular decision? Are they comfortable changing their mind when new information comes in?
None of these questions replace evaluating someone’s actual ability to do the job. They add another dimension to it.
For us, the distinction increasingly became less about whether someone could execute a task and more about whether they could understand the reason behind the task.
Consider the difference between being told to build a feature and understanding why the feature needs to exist in the first place. The first requires execution. The second requires product thinking.
Someone who understands the underlying problem can often make better decisions when the original plan changes. They can recognize when a requirement doesn’t make sense, identify a simpler solution, or spot an issue that wasn’t obvious when the work was initially defined.
That’s valuable in any company, but particularly valuable when you’re still figuring out the product yourself.
Building a Product Changes the Kind of Team You Need
Siteligent isn’t being built as a collection of disconnected services. We’re building a product company, and that has influenced how we think about the team we want to build around it.
A product doesn’t improve simply because more tasks are completed. It improves when the people building it understand the problems behind those tasks.
That means being close to the customer problem matters. It means being willing to question assumptions. It means understanding that a technically correct solution isn’t necessarily a good product solution, and that a good idea isn’t necessarily worth building.
The more we build, the more we appreciate people who are interested in those questions.
Why are we building this?
Who is it for?
Is this actually solving the problem?
Could there be a simpler way?
What are we learning from this?
These aren’t questions that belong exclusively to founders or product managers. In a small product company, good thinking can come from anywhere.
That’s one of the reasons we don’t want Siteligent to become a company where people are expected to simply execute decisions handed down to them. We want people to understand enough context to make good decisions themselves and to feel comfortable questioning something when they believe there is a better way.
Agreement is easy.
Useful disagreement is much more valuable.
If someone can explain why they think we’re approaching a problem the wrong way, and they’re willing to listen when we challenge their thinking in return, that is a healthy product conversation. It helps the company make better decisions.
Ambiguity Isn’t a Temporary Problem
One thing we have learned from building Siteligent is that ambiguity doesn’t disappear just because you create another process.
There are still going to be decisions where the information isn’t complete. There will be competing priorities, new problems, unexpected constraints and moments where several possible paths look reasonable.
The natural response is to look for more certainty before acting.
Sometimes that’s the right thing to do. Sometimes it isn’t.
At an early-stage company, waiting until everything is known can mean waiting forever. We have had to become more comfortable making thoughtful decisions with the information available, seeing what happens, and adjusting when reality gives us new information.
That doesn’t mean rushing.
There’s a difference between moving quickly because you understand what you’re doing and moving quickly because you haven’t stopped to think.
The first creates momentum. The second can create rework.
Over time, this has changed how we think about the people we want to work with. We value people who can operate without having every detail handed to them, while still knowing when they need to slow down, ask questions or get more context.
Being comfortable with ambiguity isn’t about being comfortable with chaos for its own sake.
It’s about being able to keep moving while the picture is still becoming clearer.
What We Look for Has Changed
We still look for people who are good at what they do. That’s not something we’ve moved away from.
What has changed is how much weight we put on everything around that ability.
Curiosity matters because there will always be something new to understand. Ownership matters because not every problem will arrive as a neatly assigned task. Adaptability matters because priorities change as you learn. Judgment matters because not every decision has an obvious answer. And the willingness to learn matters because no one can arrive at an early-stage company already knowing everything they will eventually need to know.
The combination is more important than any single quality.
Someone can have excellent technical skills but struggle to work without detailed direction. Someone else can be extremely curious but lack the baseline skills required for the role. Neither extreme is what we’re looking for.
We’re interested in people who can bring real capability to the table while continuing to learn, question and take responsibility for the outcome.
That is a much harder thing to capture in a job description.
It’s also much closer to what we’ve learned we actually need.
And perhaps that’s the biggest lesson so far: hiring isn’t only about deciding whether someone can do a job. It’s about deciding whether the way they think and work is compatible with the company you’re trying to build.
For an early-stage company, those decisions have a long shadow. The people who join early don’t just inherit the culture. They help create it.
What We Look for in the People Who Join Siteligent
As our thinking about hiring changed, another thing became clear: there isn’t one particular background, job title, or number of years of experience that automatically makes someone right for an early-stage company. The more useful signals are usually found in the way someone has approached the work they’ve already done.
We pay attention to people who have built something, improved something, learned something difficult, or taken responsibility for something without being pushed into doing it. That doesn’t necessarily mean starting a company or building a large side project. It can be something much smaller: taking an existing process and making it better, learning a skill because a problem required it, taking on an unfamiliar responsibility, or noticing something that wasn’t working and doing something about it.
Those experiences tell us more than a list of technologies or responsibilities on a resume can sometimes tell us.
Curiosity Is More Valuable Than Having Every Answer
There is a temptation when hiring to look for people who already know everything they will need for the role. In practice, that is rarely possible, especially at a company like Siteligent.
The product will change. The problems will change. The tools will change. The things we know today will not necessarily be the things we need to know a year from now.
That’s why curiosity matters so much to us.
A curious person doesn’t stop at the first answer. They want to understand how something works and why it works that way. They notice inconsistencies. They ask questions when something doesn’t make sense. They are willing to go down a path they haven’t explored before simply because understanding it might lead to a better solution.
This doesn’t mean questioning everything for the sake of questioning it. Good curiosity is practical. It helps someone get closer to the actual problem.
In a product company, that can be the difference between building exactly what was requested and realizing that the original request wasn’t quite the right solution.
Ownership Has to Exist Without Constant Supervision
As a company grows, processes and management naturally become more important. But early on, there is only so much structure you can put around the work.
Someone still has to notice what isn’t working.
Someone still has to make the first attempt at solving a problem.
Someone still has to say that a particular approach isn’t working and suggest another one.
That’s why we value ownership so highly.
To us, ownership doesn’t mean working longer hours or trying to prove that you can handle everything yourself. It means being willing to take responsibility for an outcome and seeing something through rather than stopping at the point where your assigned task technically ends.
If something is blocked, try to understand why. If a decision doesn’t make sense, raise it. If you see an opportunity to improve something, bring it forward. If something goes wrong, focus on understanding what happened and what should change rather than looking for someone to blame.
That kind of behavior compounds across a small team. When people trust each other to take responsibility, everyone spends less time managing the work and more time actually doing it.
We Don’t Expect People to Know Everything
An early-stage product company has a strange requirement when it comes to hiring: you need people who are capable enough to contribute from the beginning, but humble enough to recognize what they don’t know.
We don’t expect someone joining Siteligent to arrive with every answer. In fact, that would probably be unrealistic.
What matters more is what happens when they encounter something unfamiliar.
Do they try to understand it? Do they ask for help when they need it? Can they take feedback without becoming defensive? Can they learn from someone with less experience in other areas? Can they take what they learned and apply it the next time?
The ability to learn quickly becomes particularly important when the company itself is learning.
We don’t want to build a team where knowledge is locked inside individual roles. We want people to become better at their own work while also developing enough understanding of the wider product and company to make good decisions.
That creates a different kind of team over time. People become more capable not only because they gain experience in their role, but because they understand more of the system around it.
The Best People Don’t Need Everything to Be Defined
One of the hardest parts of an early-stage company can also be one of the most rewarding: things aren’t always clearly defined.
There may not be an established answer for how something should be done. A process might exist only because someone created it a few weeks ago. A product decision might need to be revisited because we learned something new.
For some people, that environment is frustrating. For others, it’s exactly what makes an early-stage company interesting.
We tend to value the latter.
Being comfortable with uncertainty doesn’t mean being disorganized. It means being able to distinguish between situations where more information is genuinely necessary and situations where the best way to get that information is simply to start.
That mindset matters because building a product involves a constant exchange between decisions and learning. You make a decision based on what you know, put something into the world, see what happens, and use that information to make the next decision better.
People who understand that process tend to work well in startups because they don’t interpret every change in direction as failure. Sometimes changing direction is simply what happens when you learn something you didn’t know before.
We Care About How People Think About the Customer
It is possible to build something technically impressive that doesn’t solve an important problem.
That’s one of the easiest traps for a product company to fall into.
A feature can be well designed. The code can be clean. The implementation can be clever. And yet the result can still fail to make someone’s life meaningfully better.
That’s why we want people at Siteligent to stay connected to the reason we’re building the product in the first place.
The customer should not become an abstract concept that exists somewhere outside the team. Decisions should eventually connect back to a real problem that someone is experiencing.
This doesn’t mean every decision has an immediate or obvious customer-facing result. Infrastructure work, internal improvements and foundational product decisions can be extremely important. But even those decisions benefit from understanding the larger picture.
The question isn’t always, “Will a customer see this?”
Sometimes the better question is, “What does this allow us to do better for customers later?”
That way of thinking helps prevent the team from becoming a collection of people optimizing their individual areas while the overall product moves in the wrong direction.
Culture Is Built Through Small Decisions
We used to think of company culture as something that would become clear naturally as the company grew.
We don’t think about it that way anymore.
Culture isn’t just the values written on an About page or the words used in a job description. It shows up in much smaller moments: how someone responds when another person disagrees with them, whether people admit when they don’t know something, whether mistakes are discussed openly, whether someone feels comfortable pointing out a problem, and whether people take responsibility when things don’t go according to plan.
Those behaviors become patterns.
Patterns eventually become the way a company works.
That’s why hiring has a cultural dimension whether you intend it to or not. Every person who joins brings their own way of communicating, making decisions, handling pressure, responding to feedback and working with others.
The more people a company has, the more those behaviors interact with one another.
For an early-stage company, the effect is even more noticeable because there are fewer established norms to counterbalance individual behavior. The people who join early have a much greater opportunity to influence what becomes normal.
That makes hiring an important part of building culture, but it also puts responsibility on the company. You can’t ask people to embody a culture that the company itself doesn’t practice.
If we want people to take ownership, we have to give them room to take ownership. If we want people to question assumptions, they need to know that disagreement is welcome. If we want people to learn from mistakes, we can’t punish every mistake as though it were a failure of character.
Culture has to work in both directions.
We Would Rather See Evidence Than Hear the Right Answer
Interviews naturally encourage people to present their best version of themselves.
That’s understandable. Candidates want to make a good impression, and companies want to make good hiring decisions.
But there is a limit to what someone can demonstrate by simply talking about themselves.
When possible, we find it much more useful to understand how someone has actually behaved in situations that required judgment, initiative or learning.
What happened when a project went wrong?
What did they do when they disagreed with a decision?
What is something they had to learn from scratch?
Have they ever taken on something outside their formal responsibilities?
What changed their mind about a problem?
The details matter more than having the perfect answer.
Someone saying they are adaptable doesn’t tell us very much. A real example of having to learn something unfamiliar, change an approach and deal with the consequences tells us considerably more.
The same applies to ownership, curiosity and problem-solving. We don’t need someone to tell us that they are proactive. We’d rather understand a situation where they actually had to be proactive.
That is one of the biggest changes in how we think about hiring: we’re interested in patterns of behavior, not just descriptions of personality.
Hiring Is Also a Decision About the Company We Want to Become
Every hire changes a small company.
Not necessarily in some dramatic or immediate way. Sometimes the effect is simply that a new person introduces a different way of looking at a problem. Sometimes they bring a skill the company didn’t have before. Sometimes they challenge an assumption that everyone else had stopped questioning.
Over time, those differences accumulate.
That’s why we don’t think about hiring purely in terms of filling an open position. The question is also whether bringing this person into the company makes the team stronger and moves Siteligent closer to the company we want it to become.
That doesn’t mean looking for people who are all the same. Quite the opposite.
A strong team shouldn’t be made up of identical personalities, identical backgrounds or identical ways of thinking. What needs to be shared is a willingness to build, learn, take responsibility and care about the outcome.
The differences in how people approach problems can then become an advantage.
We are still figuring out exactly what the Siteligent team will look like as the company grows. But we have a much clearer idea of the principles we want to preserve.
We want capable people who are curious about the problems they’re solving. We want people who can take ownership without needing every step mapped out for them. We want people who care about the product and the people using it, and who understand that their work is part of something larger than their individual role.
Most importantly, we want people who want to build.
Because that’s ultimately what we’re doing at Siteligent.
We’re not simply building a team around an existing company. We’re building the company itself, and the people who join us will have a genuine part in deciding what that company becomes.
We Know the Company Will Change
There is something slightly strange about writing down what we believe about company culture while the company is still young.
A few years from now, Siteligent will probably look different from what it looks like today. There will be more people, more customers, more products, more processes and, inevitably, more complexity. Some of the things that work naturally today will need to become more structured. Some decisions that can be made quickly by a small group will eventually require more coordination.
We don’t see that as a problem. Growth should change a company.
What we don’t want is for growth to remove the things that made building Siteligent interesting in the first place.
We don’t want people to become so separated by roles that they stop understanding the product. We don’t want processes to become more important than the problems they’re supposed to solve. And we don’t want the company to become a place where people wait for permission to do things they already know need to be done.
The challenge is not keeping a company exactly as it was when it was small. The challenge is figuring out which parts should change and which parts are worth protecting.
Keeping Ownership as the Team Gets Bigger
Ownership is relatively easy to see when there are only a few people.
Everyone knows what is happening. Problems are visible. Communication is direct. If something needs to be fixed, there aren’t many places for it to hide.
As a team grows, that changes.
Information becomes distributed. Responsibilities become more specialized. More processes are introduced because they have to be. Without being deliberate, it’s possible for people to gradually become responsible only for their own piece of the company.
That’s something we want to avoid.
Specialization is useful. People should become experts in what they do. But expertise shouldn’t come at the cost of context.
An engineer should care about the problem the product is solving. Someone working on product should understand the realities of implementation. Someone making decisions about the customer experience should be interested in what actually happens when people use the product.
Nobody needs to know everything.
But everyone should understand enough to care about the whole.
That’s the kind of ownership we want to preserve as Siteligent grows: responsibility for your work, combined with enough context to understand how that work affects everything around it.
We Don’t Want to Build a Company That Stops Questioning Itself
One of the advantages of being early is that very little feels permanent.
You can change a process because it isn’t working. You can rethink a feature because you’ve learned something new. You can admit that an assumption was wrong without having to explain why an entire organization spent six months defending it.
We want to keep some of that openness as we grow.
There will be decisions we get wrong. There will be products that need to change. There will be processes that make sense today and become unnecessary later.
That is normal.
What matters is whether people feel comfortable saying so.
A healthy product company needs people who can say, “I’m not sure this is the right approach,” without that becoming a political decision. It needs people who can disagree with an idea while still respecting the person who proposed it. And it needs leaders who are willing to change their minds when someone brings better information to the conversation.
We don’t want agreement to become the measure of a good team.
We want good thinking to be.
Building a Product Company Means Staying Close to the Product
As Siteligent grows, one of the things we want to protect most is the connection between the people building the company and the product they’re building.
It’s easy for that connection to weaken.
A company gets bigger, responsibilities become narrower, meetings increase, and eventually someone can spend an entire week working on something without seeing how it affects the person who actually uses the product.
We want to resist that where we can.
That doesn’t mean everyone needs to be involved in every product decision. That would be inefficient and eventually impossible. It means maintaining enough context that people understand what they’re contributing to and why it matters.
The product should remain something the team feels ownership of, not something that is simply handed down through a series of tasks.
This is also why customer understanding matters to us.
The closer we stay to the actual problems website owners face, the easier it is to distinguish between building something because it sounds useful and building something because it genuinely makes the product better.
That distinction becomes increasingly important as a company grows and the number of possible things to build grows with it.
There Is No Final Version of the Team
One of the things we’ve become comfortable with is that the team we need today may not be exactly the team we need tomorrow.
That doesn’t mean constantly changing people or chasing whatever skill happens to be fashionable. It means recognizing that companies evolve, and the capabilities required to build the next stage of the company evolve with them.
Someone joining Siteligent today may eventually take on responsibilities that didn’t exist when they joined. A role may change as the product changes. Someone may discover an area they’re particularly good at that wasn’t obvious at the beginning.
That’s part of the opportunity of joining early.
We want people to have room to grow rather than treating a job description as a permanent ceiling.
At the same time, growth shouldn’t mean losing the qualities that made someone valuable in the first place. Curiosity, ownership, good judgment and a willingness to learn remain important regardless of title.
If anything, they become more important as responsibility increases.
What We’ve Learned About Hiring
Looking back, the biggest change in our thinking isn’t that we’ve discovered a secret formula for hiring.
We haven’t.
It’s that we now understand how much context matters.
The right person for an early-stage startup isn’t necessarily the person who looks most impressive on paper. It isn’t necessarily the person with the most years of experience or the longest list of technologies.
It’s someone whose way of working fits the reality of what we’re trying to build.
Someone who can be highly capable without believing they have nothing left to learn. Someone who can take direction without needing every decision made for them. Someone who can care deeply about their own work while still thinking about the product as a whole.
And perhaps most importantly, someone who genuinely wants to be part of the building process.
That last part is difficult to measure in an interview.
You can ask questions. You can look at previous work. You can talk through problems. You can learn about someone’s experience.
But eventually, there is still an element of judgment involved.
That’s why we’ve become less interested in finding a perfect candidate and more interested in understanding how someone actually thinks and works.
We Are Still Learning
It would be easy to write an article like this and make it sound as though we started Siteligent with a clearly defined philosophy about hiring and culture, followed it perfectly, and arrived at a set of conclusions.
That wouldn’t be honest.
Our thinking has changed because the company has changed. We have changed. The product has changed. And the things we’ve learned from building have changed the way we look at the next decision.
We expect that to continue.
Some of the principles we care about today may need to be reconsidered as the company grows. New challenges will force us to think differently. Some things that seem obvious now may become much more complicated later.
That’s part of building a company.
The goal isn’t to create a document that tells everyone exactly how Siteligent will work forever.
It’s to be deliberate enough about what we’re building that we notice when we’ve started moving away from the company we actually want.
The Company We Want to Build
Ultimately, the kind of company we want Siteligent to become isn’t defined by a list of perks, a particular office, a certain number of employees, or even a set of words on a careers page.
We want it to be a place where capable people can do meaningful work and have enough trust and context to do that work well.
A place where people can ask difficult questions.
A place where someone can say they don’t know something and then go and learn it.
A place where taking ownership is encouraged rather than punished with endless responsibility.
A place where the product matters, the customer matters, and the quality of the work matters.
And a place where people who join early can look back years later and know that they didn’t simply work at Siteligent.
They helped build it. That’s probably the simplest way we can describe what we’ve learned so far.
Building a company changes your ideas about hiring because you eventually realize that you’re not just deciding who can help you complete the work in front of you. You’re deciding who you want beside you while the work itself is still being figured out.
Every person changes the company in some way. Every decision becomes part of its history. Every habit that gets repeated eventually becomes part of its culture. So we’re going to keep learning.
We’re going to make mistakes. We’ll probably change our minds about some of this. We’ll discover new things we couldn’t have anticipated when we started.
But that’s okay. Siteligent is still being built. And so is the company behind it.