We enjoy what we do, and we want to spend as much time as possible on it and as little time as possible on the cumbersome details: complex offers, contracts, pitches, presentations, complicated written assurances, politics, etc. Our clients trust us, and we trust our clients. It is important for us to invest in this trust and familiarity. Many of the thoughts, ideas, and concepts that are fundamental to the thinking and actions of Klickmeister aim at trust and familiarity.

We stick to agreements and are open and honest with our clients and within the team. We only promise things that we can keep. That doesn’t mean we don’t make commitments, as the team/client needs commitments to feel secure and be able to orient themselves. However, when we make commitments, we keep them. Conditional commitments or smaller steps are also acceptable.

We fully endorse the Agile Manifesto:

Individuals and Interactions over Processes and Tools
The focus is on people, and direct communication is more important than formalities. This means that no matter how sophisticated and well-documented a process is, it cannot replace a personal conversation. Personal exchange is crucial; it helps individuals, teams, and projects. The individuals involved in our projects are not just part of a process chain; they are people with needs and goals. Knowing and caring about these people is tremendously helpful. The greater the familiarity and trust, the easier the collaboration. This positively impacts the working atmosphere and the project.

Working Software over Comprehensive Documentation
Concrete work results instead of checklists, slide decks, or long emails. In large organizations with a traditional project culture, more time is often spent creating slide decks for steering committees than on completing the actual task. As a client recently aptly put it, “here, we once again have more managers in the project than people working on the product…”. We want as much of our time and, consequently, as much of the budget as possible to be visible in the work results. We need to be mindful of this. If a 3-minute phone call can clarify the matter, we prefer it over an email that would take 15 minutes to write. If the Product Owner or sponsor needs input for their presentation, we ask if bullet points are sufficient, etc.

Collaboration with the Clients over Contract Negotiation
The client plays a central role in the work of our teams. With their needs and issues, they are an essential part of the team. A (personal) engagement with the client is more important than a formal and watertight contract. This point, too, places direct exchange above formalities. The goal is to work together with the client and other process participants as a unified team. There is a direct dependency. We don’t want to fall into an “us-against-them” mode. This becomes apparent in projects when attempts are made to build “paperwork” that can be used as a basis for demanding things. This doesn’t mean that we don’t want to write or document anything, but it means that we don’t want to create paperwork that then needs to be worked against. It is essential to interact with individuals and address individuals. Once we abstract, an “us-and-them” or, worse, an “us-against-them” mentality forms. Cooperation becomes more challenging at this point. Therefore, speak with and to individuals instead of “the translators,” “management,” or “IT.”

Responding to Change over Following a Plan
As an organization and team, we are very flexible and adaptable. However, this does not mean that we operate without a plan, arbitrarily, or chaotically. We are focused on a goal but also willingly deviate from the original plan if it makes sense for us and the project, with the prospect of providing a higher value contribution. Extremely important! A plan should give us a structure to reach a goal. The goal is to get as close to the goal as possible, not to follow the plan. That is a fundamental difference. Often, the attitude is as follows: we have a goal and make a plan to achieve this goal. From then on, only the plan is pursued. Sometimes, the goal is lost sight of. We learn along the way, and that changes the plan and sometimes the goal.

We respect and appreciate others, their work, and their work results, even if others may act differently than we would wish. We do not mock or belittle others, their behavior, or their work; instead, we take them seriously and value them. The same applies to us and our own work. It helps to assume that others are usually doing or have done their best within the specific framework. A small expression of appreciation (technical term: praise) usually makes the world a little better, pleases others, and acts as a lubricant for teams and projects.

People must be excited to work with us.

We strive to position ourselves and behave in a way that makes others enjoy working with us. This can happen in various ways, and these are not exclusive but can be combined in any way. Birger introduced the division of employees and team members into energy givers and energy consumers to us pretty early in the history of Klickmeister. This is, of course, a very simplified view and does not recognize the complexity of the other person. Still, it is a helpful way of thinking that can be applied not only in a professional but also in a personal context.

We should always be energy givers! Energy can be provided to the team, project, or meeting in various ways. Here are a few examples: good mood, positive aura, serious engagement with the project, team motivation, highlighting difficulties, giving trust…

At least that’s how Stromberg put it. Not everything we do is super cool and incredibly fun. We should try to make it so, or at least, the proportion of things that make us happy/satisfied should be as large as possible. But it will never be everything. We have to accept that. However, if we realize that we no longer feel like being part of Klickmeister, please let us know in time because we can change quite a bit, comparatively. Not everything and often not immediately, but with a little lead time, quite a bit.

Our client relationships and, consequently, our projects are highly long-term. Thus, we often work within an existing framework and rarely on a greenfield project. It is helpful to understand and accept this, especially for those who are relatively new to the job. Unlike in academia, we rarely have the opportunity to change the tech stack or easily switch to a different stack in the next project. Much has evolved historically and cannot be changed quickly.

Code, technology, and methodologies change extremely rapidly in our industry. The mentality of “we should completely redo this” is often not very helpful here. The project that might have been based on the hot framework X a few years ago is something no one wants to touch with a ten-foot pole today. However, if we completely refactor it today, the same thing will happen in a few years. This doesn’t mean that we don’t want to do refactoring; on the contrary, we do it for the client’s economic motivation and not solely to improve the developer experience.

It helps to recognize that the team that created the product at time X acted to the best of their knowledge and conscience (see Appreciation) and that the technology used, if it serves its purpose, is meaningful and appropriate. Also, it’s helpful to be aware that everything we build today will likely elicit an “oh dear” from us in 10 years because hindsight is always 20/20, and, of course, we’d-know-better-now mentality 😉.

In our work and the development of our software solutions, we are committed to a conscious and sustainable use of natural resources. We implement strategies that use energy efficiently and responsibly. Our goal is to minimize the ecological footprint of everything we do.

We appreciate our freedom of space. Unfortunately, we can’t always choose everything (tasks, assignments, working hours, collaboration partners, etc.). Nevertheless, we have quite extensive freedom. The most significant freedom is undoubtedly the temporal and spatial flexibility. Since 2010, Klickmeister has embraced virtualization strongly, and with the C-19 pandemic, our clients have become significantly more location-independent. We aim to preserve and leverage this flexibility. Working from home, working from the office, working from a vacation home. Everything is possible.

We create web and web-based software. At the end of the day, our clients want functional, usable, and high-quality products from us. It’s a rewarding job where, if everything goes well, we can experience flow. It’s beautiful, enjoyable, and beneficial for the product.

However, this only works when we have sufficient contiguous periods to get into the zone. Every meeting, every chat, every notification is a distraction. Therefore, we strive to block as much time as possible. Meetings and discussions are crucial, but they tend to be perceived as more important than flow development time. However, that’s not the case. If we don’t have time for concentrated development, we won’t end up with a product in hand, no matter how well we’ve communicated.

Miriam once coined the beautiful phrase: “I don’t work in the emergency room here.” And that’s true. Of course, we do extremely important things, but usually, no lives are hanging in the balance. In our context, all deadlines are human-made. They don’t follow the laws of nature and are therefore changeable. We want to work with joy in the long run. And we need to be mindful of that. It’s better to say, “No problem, we can deliver that feature the week after next,” than to say, “Okay, I’ll try to get it done by Tuesday somehow.” Incompatibilities should and can be made explicit: “If it’s supposed to be done by Tuesday, X and I would have to work on it on Sunday, is it really that crucial?” or “If it’s supposed to be done by Tuesday, we’ll have to leave this or that aside for now, does that work?” Saying No is a legitimate response. And, generally, we don’t need to justify this No in detail.

We try to minimize external pressure internally—a rational consideration of facts often helps with this. And, importantly, we don’t pass on the pressure to others. We don’t want to be driven, and others don’t want that either. We can inform and justify priorities objectively. There’s no need to unnecessarily release cortisol.

Language has a surprising influence on thinking and, consequently, on action. We strive to act professionally. Unfortunately, in meetings and other communication situations, interestingly, especially by developers, terms like “basteln” (tinkering), “frickeln” (fiddling), “fummeln” (fumbling), “wimmsen,” “kloppen” (banging), “tackern” (tacking), etc., are often used. “I’ve already tinkered with something there,” “We just need to bang the data in there,” “I just have to tack the overlays in there,” sounds a bit amusing, but it’s not very respectful and professional.

We assess the appropriateness of the terms we use. We don’t need to unnecessarily complicate our work through complex language and terms, but we should use a value-based, understandable, and professional language in a friendly, binding, and relaxed tone. Please, no bureaucratic language. Thank you!

We should try to make our working hours as positive as possible. If something is missing, we address it and try to improve it. It doesn’t matter initially whether it’s about other projects, a different structure of the team meeting, more or less working time, hardware or software, or a HomePod. Not everything is possible, but asking costs nothing. We cannot compensate for deficits that we are not aware of.

We want to improve, in coding, in conceptualizing, in team interaction, etc. Every idea on how we as an organization or individual teams, projects, etc., could get better is valuable. We use meetups, workshops, discussions, and training sessions. Especially meetups provide ideas, inspiration, and help in assessing our strengths and weaknesses.

We share our knowledge within the team. We aim to have important projects with a driver and a co-driver. For every crucial project, we want to be able to switch the roles of driver and co-driver, and it should be possible for the driver to be on vacation or sick. Responsibility for this lies not with the business or team management but with each driver individually. Please, at regular intervals, everyone should review their projects and topics to ensure there are corresponding co-drivers and that they are capable of acting independently in the project. If not, we empower them to do so.

Emails
We usually don’t need extensive safeguards. This is all the more reason to keep email distribution as small as possible. This way, we also receive fewer emails ourselves. When composing emails, the tone should be friendly, professional (but not formal), relaxed, concise, and understandable. For complex topics, it is very helpful to give a heads-up or engage in a brief phone call with the recipient or key stakeholders, especially when the email is addressed to multiple people. We do not use uppercase letters in the subject! Never!

Talking Helps
Emails are great. But for many things, they are completely unsuitable. In a phone call or voice chat, many things can be clarified or explained more easily, casually, and much faster.

Strategic Informality
We try to avoid a formal “Sie” (you) and informal “Du” (you) distinction within teams. It’s not always possible, but often. The goal should be: if one of us addresses the client informally, then everyone does. Using “Du” (informal) reduces distance and promotes a partnership. If we are unsure about communication, we ask the team or the client directly, for example, “I hope it’s okay if I use informal language; otherwise, please let me know…”.

Every meeting needs a goal. Everyone should know what their goal is before a meeting. If you don’t know, you might not be relevant to the meeting. The best thing about meetings is that you can make a little small talk and get to know people better. Use that opportunity! So don’t just come in, say “Hello,” open your laptop, and check emails; instead, come in, say “Hello,” and chat a bit. It always helps!

We make sure not to attend too many meetings, and the frequency of meetings dictates at most half of our working days. No software project has ever been completed by having too many meetings.

For important meetings, we coordinate with key individuals beforehand to avoid surprises during the meeting itself. It’s often very helpful to discuss a problematic or important topic with the “biggest opponent/doubter/opposer” beforehand.

The joke about Dailys: they happen every day. Who would have thought? They should be as short as possible. We make sure to be brief and only discuss things that involve multiple participants. Anything else is clarified outside of Dailys. We point out if a Daily takes too long or if topics are discussed that don’t belong in the Daily. Anything lasting longer than 20 minutes slows us down. We are alert during the Daily, have our finger on the mute button, and don’t read emails or other stuff in parallel!