How Lexware Office Teams Hire Their Own Colleagues

This article is based on an online session with the Sociocracy 3.0 community in March 2023, in which people from Lexware Office shared how their team recruiting process developed, what they learned and the questions they were still exploring.

In many organisations, the people who will work most closely with a new colleague have limited influence over who gets hired. HR coordinates the process, managers approve the role, and the team is consulted somewhere along the way.

At Lexware Office, teams take responsibility for much more: identifying the need for a new colleague, shaping the role, reviewing applicants, interviewing candidates and deciding whether to move forward. That responsibility continues after the contract is signed, through onboarding and the probation period.

Yet this is not a story about replacing HR with an informal team vote. Lexware Office has developed a recruiting process with coordinating roles, shared standards and support from people beyond the team. Along the way, it has discovered that involving those affected does not necessarily mean involving everyone in every step.

The result is an instructive example of how distributed authority can work in a consequential organisational process—and how it continues to develop through experience.

When recruiting becomes a team responsibility

Lexware Office provides online software for bookkeeping, invoicing, payroll and related business processes in Germany. The experience shared at the S3 community session concerned an area of the organisation that had grown from a single Scrum team to around 200 people at the time of the Case Study session.

Over the years, its teams drew on Scrum, agile values, Google re:Work, sociocracy, Liberating Structures and, increasingly, Sociocracy 3.0 (S3). S3 did not arrive as a packaged transformation programme. Some practices had already emerged through experimentation; learning more about S3 later helped colleagues make those practices more explicit and develop them further.

As a software business serving customers with changing needs, the area had to keep adapting both its products and the way it worked. Growth made previously informal arrangements less reliable. More colleagues needed to coordinate across teams, and decisions that had once happened through quick conversations required clearer responsibilities and shared expectations. Recruiting became one place where that broader organisational learning was particularly visible.

The recruiting process shows what that evolution looked like in practice. Cross-functional teams already reflected on their work through retrospectives and health checks. Their responsibility extended beyond delivering products or services to recognising when their capacity, capabilities or arrangements needed to change.

If the team was to work with a new colleague, why should it not be involved in deciding whether that colleague was needed and who would join?

Hiring starts with a need

A recruiting process often starts with a tension: someone notices a gap between what is happening and what they believe is needed. Perhaps the team is overloaded, a skill is missing, a domain is not being adequately cared for, or customer growth has increased demand on support. A market opportunity might emerge that nobody has enough capacity to pursue.

In S3 terms, colleagues Navigate via Tension, paying attention to what they notice in their work, and Respond to Organizational Drivers when a situation calls for an organisational response. Rather than treating every expression of tension as a request to hire, they ask what is actually required.

The important question is not simply, “Can we hire?” but “Would recruiting be an appropriate response to this need?”

At Lexware Office, the people concerned can clarify the need, develop a proposal to recruit and use Consent Decision-Making to decide whether to proceed. The organisation also had planned open positions that teams could draw upon as needs became clear.

Teams therefore have room to initiate recruiting, but not an unrestricted right to hire anyone at any time. The process links an observed need to a considered decision, rather than relying solely on a top-down headcount plan or an individual’s preference.

For example, a support team noticing a sustained rise in customer requests may have good reason to ask for additional capacity. But a vacant position is not automatically the answer. Before recruiting, people need to consider what is missing, whether the existing work can be organised differently, and whether a new colleague would address the actual situation. The session described an approach driven by such conversations rather than by a manager identifying a vacancy in isolation.

This is a practical expression of Involve Those Affected: the people closest to the work can bring relevant knowledge into a decision whose consequences they will help manage.

Recruiting begins with a need the team can recognise — not simply a vacancy someone else has decided to fill.

 

A hiring lead, supported by a community

Once a team decides to recruit, someone takes on the role of Hiring Lead. This is not necessarily a manager, or even a permanent job title. It is a specific Role for coordinating the work of recruiting.

The Hiring Lead knows the guidelines, helps the team clarify the skills it needs, supports the job description, coordinates communication with candidates and keeps the process moving. But the role does not transfer every recruiting decision to one person. Other team members remain involved where their knowledge and perspective are needed.

Scrum Masters often take the role because facilitation and coordination are already part of their work. The session also described developers and support colleagues doing it. In one area, Lexware Office introduced a Hiring Lead Enablement role to support people who were new to the responsibility. Coaching, feedback, leading by example and short Retrospectives after interviews all helped Hiring Leads improve.

That support matters because many of the tasks can be unfamiliar to someone whose main work is product development or customer support. A new Hiring Lead might know the team and the technical requirements very well, but have less experience with interview preparation, candidate communication or how to handle a disappointing outcome respectfully. In the learning sessions described by participants, simple questions such as “How did it go?” and “What should we do differently next time?” helped build that capability.

As more teams began recruiting, Lexware Office also needed a way to maintain shared standards without bringing every decision back to a central authority. It created a Hiring Leads Community of Practice: a forum for people involved in recruitment to compare experiences, improve guidance and learn together.

The community could refine the Hiring Lead role description, exchange practical interview exercises and discuss sensitive situations such as how to reject candidates respectfully after several rounds of interviews. It also created a collaboration agreement for its own work.

Rejection is a good example of why these conversations matter. When a person has already invested time in a task and several interviews, the quality of the response can affect both their experience and the organisation’s reputation. Teams need ways to give timely, considerate and useful feedback, while being clear about the outcome. Sharing experience across the Community of Practice allowed colleagues to establish common expectations without taking direct responsibility for every conversation away from the teams.

A programming exercise developed by one team, for instance, could become useful to others. Difficult experiences with candidates could inform better expectations and communication across teams. Learning no longer had to remain local.

One participant described the community as common ground for a decentralised process. The distinction is worth emphasising: team autonomy did not require teams to work in isolation, and shared standards did not require a return to centralised hiring decisions.

Autonomy does not mean fragmentation. Shared standards do not have to mean central control.

 

Involving the right people at the right time

Once applications arrive, people from the team review them. They understand the actual work, the skills needed and the kind of collaboration the role involves. Candidates also speak directly with prospective colleagues rather than interacting exclusively with HR.

Participants reported positive feedback about this direct contact, as well as occasions when a team responded within hours of receiving an application. In one story, a developer planned to apply to several employers but received such a quick response from Lexware Office that he never got around to the others. The example is anecdotal, but it illustrates how moving decisions closer to the people with the relevant information can sometimes improve responsiveness.

That speed does not come from compressing every interview or avoiding careful consideration. It comes partly from reducing handoffs. When the people reviewing a candidate can also arrange a conversation and decide what they need to know next, they need not wait for every intermediate judgement to pass through a separate managerial chain. The value is especially clear when promising candidates are considering several opportunities at once.

The team also learned that participation can slow things down when it is poorly designed. One group of around ten initially tried to involve everyone in reviewing every application and deciding whom to invite to the first interview. The process became too slow, and good candidates were missed.

They did not respond by abandoning team involvement. Instead, they became more selective about when it mattered. A smaller group could screen applications and conduct an initial conversation; the wider team could participate later, when its perspective was more valuable.

This is an important practical distinction. Involve Those Affected is not an instruction to put everyone in every meeting. Teams can delegate specific steps while ensuring that the people who will be meaningfully affected retain appropriate influence over important decisions.

Involving those affected is not the same as maximising the number of people in every meeting.

 

Deciding together: interviews and consent

At the time of the session, Lexware Office generally described three stages in the recruiting process.

The first was a short introductory conversation, often around half an hour, involving the Hiring Lead and one or two team representatives. The second brought in a wider group for a more substantial discussion of professional and team fit. For some roles, candidates completed a task beforehand so that the interview could explore how they worked and reasoned through practical problems.

This gives both sides opportunities to learn different things. An initial conversation can establish whether it makes sense to invest more time together. A practical task or deeper discussion can reveal more about professional competence, how a candidate approaches unfamiliar problems and what kinds of questions they ask. Meeting more colleagues also helps the candidate gain a less filtered impression of the people and environment they might join.

The third stage concerned contracting. Here, team authority still had a boundary: salary negotiation and contracting were handled by the managing director, rather than fully delegated to the team.

After interviews, the hiring team used Consent Decision-Making. Four questions helped structure the conversation:

1. Is the candidate a fit for the job? Do they have the expertise and experience needed for the work?
2. Is the candidate a fit for the purpose? Can they contribute to what the team and organisation are trying to achieve?
3. Is the candidate a fit for Lexware Office’s culture? Can they work effectively within its practices and expectations, including self-governance?
4. Is the candidate a fit for me personally? Can I see us working together constructively?

The fourth question invites particular care. Working relationships do matter. But a personal preference or an initial lack of rapport is not, by itself, the same as a reasoned objection to hiring someone. The group needs to examine the reasons behind concerns, including whether they point to genuine risks for the work or collaboration, rather than treating individual likes or dislikes as decisive.

Concerns may lead to useful next steps. If the team is uncertain about how a candidate approaches self-governance, it can explore that question in a subsequent conversation. If colleagues are uncertain about working together, a one-day trial might offer a better basis for judgement. Other concerns might be addressed through a deliberate onboarding plan.

The distinction between an unresolved concern and a reasoned objection is particularly important here. A concern can signal uncertainty without yet demonstrating why proceeding would be unsafe or ineffective. Rather than discarding the concern or letting it become an unexamined veto, the team can investigate it. Sometimes a targeted question or a practical exercise will be enough. Sometimes the information uncovered will materially affect the proposal to hire.

One participant also described an occasion when nobody had raised a formal objection, yet many concerns had accumulated and the team chose not to proceed. That example is worth exploring carefully. It shows that concerns can contain important information, but the account does not establish precisely how the group arrived at its final decision.

Consent is not a search for unanimous enthusiasm. It helps people examine arguments, identify meaningful risks and make a decision they have reason to believe is good enough and safe enough to try. That requires more than simply counting who likes a candidate.

Responsibility doesn’t end with hiring

At Lexware Office, accepting an offer is not the end of the team’s responsibility. A new colleague is usually supported by a buddy who knows the same or a related area of work. Developers may support developers, Scrum Masters may support Scrum Masters, and support colleagues may help new members of the support team.

The buddy role makes practical help visible and dependable. It includes helping the newcomer understand the team, expectations, systems and ways of working. Teams use onboarding documents covering practical arrangements, contacts and plans for the early days or weeks. Some information can be provided before the person’s first day.

During the first weeks, daily check-ins create space to talk about what is going well, what feels unclear and where help is needed. The new colleague can also say whether the organisation is meeting their expectations; fit is not a one-way judgement.

The original four recruiting questions provide a useful thread through the probation period. The team can return to questions of job capability, contribution to purpose, ways of working and relationships, now with the benefit of real shared experience rather than interview impressions alone. Equally, the new colleague can test assumptions made during recruitment and raise issues the team may not have anticipated.

The process continues through the six-month probation period. Lexware Office described a newer practice called a hiring check, held twice during that period. The Hiring Lead brings together the hiring team and other affected people to reflect on the original recruiting questions and any new information. Feedback is then shared with the colleague, giving them an opportunity to respond, learn and adapt.

This can involve uncomfortable decisions. One participant described a case in which the team eventually decided not to continue the employment relationship. The former employee reportedly said that, although the outcome was difficult, the process had felt fair because expectations and concerns had been communicated and she had an opportunity to respond.

The example matters precisely because it is not a simple celebration of empowerment. Teams involved in choosing colleagues also need to offer support, give candid feedback and face difficult questions when collaboration is not working.

Team ownership is not only about empowerment. It includes discomfort, accountability and care.

 

What they’ve learned and what remains unresolved

The process developed over years, not through one complete redesign. Several lessons emerged as Lexware Office grew.

Make roles and standards explicit. Practices that work informally within one small team become harder to coordinate across many teams. Participants said they would, looking back, have written role descriptions and shared useful practices earlier. The Community of Practice provided a place to Evaluate and Evolve Policies and other working agreements as experience accumulated.

Recognise recruiting as real work. Reviewing applications, preparing interviews, contacting candidates and making considered decisions all take time. That work needs to be accounted for alongside other team commitments. In one example from the session, hiring a colleague became an explicit sprint goal.

Balance participation with speed. The experience of involving ten people in every initial screening showed that broad involvement is not always the most effective approach. Careful delegation can make room for both speed and meaningful participation.

Make authority boundaries clear. Contracting and salary negotiation remained with the managing director at the time of the session. Participants described this as a bottleneck, and a question they had not yet resolved satisfactorily. Salary ranges existed, informed by internal structures and market data, but greater salary transparency raised difficult questions about fairness, expectations and conversations between colleagues.

Adapt when the team does not yet exist. When an established team needs a new colleague, it is relatively clear who will be affected. When recruiting for a team that is still being formed, the answer is less obvious. Lexware Office was still exploring how to involve the right people in those decisions.

There were also open questions about how HR should support or participate in the process and how recruiting authority related to budget and formal employment decisions. The session account does not provide enough detail to settle these points.

The role of common standards was another recurring theme. Teams wanted enough consistency to give candidates a fair and recognisable experience, but also enough flexibility to respond to different kinds of work. A developer recruitment process may call for a technical exercise; a support role may need another way of examining capability. Treating shared guidance as something that can be reviewed and improved was more useful than assuming one detailed procedure would fit every situation.

These limits do not erase the progress the teams had made. They show that self-governance involves recurring decisions about what authority to distribute, what support to provide and where shared constraints remain useful.

Self-governance does not remove trade-offs; it asks people to make them more visible.

 

Recruiting by those affected: lessons for others

The most interesting part of Lexware Office’s story is not that it found a universally applicable recruiting model. Its practices emerged in a particular context: a growing software product organisation with cross-functional teams, experience of agile working and an increasing commitment to distributed authority.

The transferable insight is more specific. Recruitment decisions affect people’s work, relationships and capacity to deliver value. The people who will live with the consequences often have information that can improve those decisions. At Lexware Office, they are involved from the first recognition of a need, rather than merely asked for an opinion after the process has already been shaped elsewhere.

Yet the story also challenges the idea that more participation is always better. Involving everyone at every step became an obstacle until teams learned to distinguish between the decisions requiring broad involvement and the tasks that could sensibly be delegated. Clear roles helped people coordinate the work, while the Community of Practice helped teams learn from one another without centralising every decision.

There is a wider organisational lesson here. Decentralisation succeeds or fails partly through the quality of the agreements around it. Teams need to know what they can decide, when others must be involved, and where they can turn for help. Without that clarity, authority can drift back to managers or become mired in meetings. With it, people can take responsibility without having to carry every part of the process alone.

Perhaps the most substantial shift is what happens after someone joins. If a team helps decide whom to recruit, it cannot treat onboarding, feedback or a difficult probation decision as someone else’s problem. The responsibility to participate extends into the relationship that follows.

For organisations curious about applying S3, the invitation is not to copy Lexware Office’s three interview rounds, four questions or community structure. It is to identify a real need, involve people where their perspectives matter, create enough clarity to proceed, and learn from what happens.

Recruiting by those affected is not a finished state of self-governance. It is one way of making shared responsibility part of everyday work.