Love

❤️

We care about the people we work with, once people are feeling loved they are able to love others. This enables us to achieve more progress, which makes our work more fulfilling.

Listening well

When we take the time to listen to God, ourselves and others well, we eliminate a lot of misconceptions and save significant time in moving the company forward. We practice Christian listening methodology by Aloe Christian Foundation (link here and excerpt here).

Self-service and self-learning

Service and learning to ourselves is a practice of self-love. As we grow in these areas we are better able to help others in self-love too. We are to love others as we love ourselves. It starts with us.

Be respectful of others' time

Our time is a precious resource and respecting others’ time is an amazing way to love others. Consider the time investment you are asking others to make with meetings and a permission process. Ensure that you are fully present when meeting with someone as an act of love. Avoid unnecessary meetings, and if one is necessary, try to make attendance optional for as many people as possible. Any meeting should have an agenda linked from the invite, and you should document the outcome. Instead of having people ask permission, trust their judgement and offer a consultation process if they have questions.

Spend company money like it's your own

Every Rand we spend will have to be earned back; be as frugal with company money as you are with your own.

Frugality

Amazon states it best with: "Accomplish more with less. Constraints breed resourcefulness, self-sufficiency, and invention. There are no extra points for growing headcount, budget size, or fixed expense."

Trust

We believe that collaboration moves as the speed of trust (Peter Drucker). We also believe that trust develops one conversation at a time. Therefore, quality and intentional time spent together is a golden resource at Techmission.

Managers of one

We want each team member to be a manager of one who doesn't need daily check-ins to achieve their goals.

Freedom and responsibility over rigidity

When possible, we give people the responsibility to make a decision and hold them accountable for that, instead of imposing rules and approval processes. You should have clear objectives and the freedom to work on them as you see fit. Freedom and responsibility are more efficient than rigidly following a process, or creating interdependencies, because they enable faster decision velocity and higher rates of iteration.

Identity

We should remember where our identity lies. We are not our mistakes and we are loved despite our mistakes and even because of our mistakes. Not every problem should lead to a new process to prevent them. Additional processes make all actions more inefficient; a mistake only affects one.

Embrace change

Adoption of features, user requirements, and the competitive landscape change frequently and rapidly. The most successful companies adapt their roadmap and their organization quickly to keep pace. One of the things that makes this challenging is the impact on our team. People may need to change teams, subject matter, or even who manages them. This can rightly feel disruptive. If we coach ourselves to embrace the positive aspects of change, such as increased opportunity and new things to learn, we can move faster as an company and increase our odds of success. It is important to hold management accountable for being deliberate.

Say why, not just what

Changes have the reasons for the change laid out clearly along with the change itself. This leads to fewer questions later on because people already have some understanding. A change with no public explanation can lead to a lot of extra rounds of questioning, which is less efficient.

This also helps with institutional memory: a year from now when you want to know why a decision was made, or not, the issue or MR that has the decision also shares why the decision was made. This is related to Chesterton's fence - it's much easier to suggest removing or changing something if you know why it exists in the first place.

Avoid using terms such as "industry standard" or "best practices" as they are vague, opaque, and don't provide enough context as a reason for a change.

Similarly, merely stating a single value isn't a great explanation for why we are making a particular decision. Many things could be considered "iteration" or "efficiency" that don't match our definition of those values. Try to link to a sub-value of the value or provide more context, instead of just saying a single value's name.

Saying why and not just what enables discussion around topics that may impact more than one value; for instance, when weighing the efficiency of boring solutions with the focus on customer results. When decisions align with all of our values, they are easy to discuss and decide. When there are multiple values involved, using our values hierarchy and directly discussing the trade-offs is easier with more context.

Articulating why also helps people understand how something changed when you articulate that you changed your mind.

Saying why does not mean justifying a decision against all other suggestions. The DRI is responsible for their decision. The DRI is not responsible for convincing other people, but they should be able to articulate their reasoning for the change.

When a Techmission Team Member comes across an ask or material (MR, handbook, etc.) that does not provide a "why" with sufficient context, the Team Member is responsible for getting the why and, if needed, working with the DRI to ensure that it is adequately documented and communicated to give context to other team members. In the absence of a why, team members may speculate the why. This is something that can lead to disruption and inefficiency.

Transparency

Be open about as many things as possible. By making information public, we can reduce the threshold to contribution and make collaboration easier. Use public issue trackers, projects, and repositories when possible.

An example is the public repository of this website that also contains this company handbook. Everything we do is public by default, such as the Techmission issue trackers, as well as marketing and infrastructure. Transparency creates awareness for Techmission, allows us to recruit people that care about our values, gets us more and faster feedback from people outside the company, and makes it easier to collaborate with them. It is also about sharing great software, documentation, examples, lessons, and processes with the whole community and the world in the spirit of open source, which we believe creates more value than it captures.

There are exceptions. Material that is not public by default is documented. We are above average at keeping things confidential that need to be. On a personal level, you should tell it like it is instead of putting up a poker face. Don't be afraid to admit you made a mistake or were wrong. When something goes wrong, it is a great opportunity to say "What’s the kaizen moment here?" and find a better way without hurt feelings.

Public by default

Everything at Techmission is public by default. If something is not public, there should be a reference in the handbook that states a confidential decision was taken with a link to our Not Public guidelines, unless legal feels it carries undue risk. The public process does two things: allows others to benefit from the conversation and acts as a filter. Since there is only a limited amount of time, we prioritize conversations that a wider audience can benefit from.

If you believe something shouldn't be public that currently is (or vice versa), then make a merge request to the relevant page(s) suggesting the change so that you can collaborate with others and discuss with the DRI.

Not public

We make information public by default because transparency is one of our values. However it is most important to focus on results. Therefore, a category of information is public unless there is a reason for it not to be.

Value dissent

In a group setting, participants may disagree with a proposal but not articulate their views for one reason or another. As a result, everyone loses out on their feedback. Dissent is expression of that disagreement, however, it can be difficult and even socially expensive. Expression of feedback is a way for everyone to grow and learn, and is based on facts rather than opinions. Share your perspective, rather than agreeing simply to avoid conflict or to go along with everyone else.

Articulate when you change your mind

If you state one thing, and then change course and support a different direction, point, or outcome, articulate this. It is OK to have your position changed by new data. Articulating that an earlier stance is not your current stance provides clarity to others and encourages data-driven decision making.

Surface issues constructively

Be transparent to the right people (up) at the right time (when still actionable). If you make a mistake, don't worry; correct it and proactively let the affected party, your team, and the CEO know what happened, how you corrected it, and how—if needed—you changed the process to prevent future mistakes.

Anyone and anything can be questioned

Any past decisions and guidelines are open to questioning as long as you act in accordance with them until they are changed.

Disagree, commit, and disagree

Everything can be questioned, but as long as a decision is in place, we expect people to commit to executing it, which is a common principle. Every decision can be changed; our best decision was one that changed an earlier one. In a manager-report circumstance, usually the report is the DRI. The manager may disagree with the final decision, but they still commit to the decision of the DRI.

When you want to reopen the conversation on something, show that your argument is informed by previous conversations and assume the decision was made with the best intent. You have to achieve results on every decision while it stands, even when you are trying to have it changed. You should communicate with the DRI who can change the decision instead of someone who can't.

Love Competency

Competencies are the Single Source of Truth (SSoT) framework for things we need team members to learn. We demonstrate efficiency when we work on the right things, not doing more than needed, and not duplicating work.

Techmission Love Grade

Demonstrates Efficiency Competency by…

Knowledge Assessment

* Developing an understanding of being a manager of 1: Take responsibility for your own tasks and deliver on commitments

* Brings up ideas for process improvements to 1:1s. * Learns to write everything down as it is far more efficient to read a document at your convenience than to have to ask and explain.

Knowledge Assessment for Individual Contributors

* Has a growing understanding of efficiency and is acting by surfacing process inefficiencies in the team

* Seeks out ways to be more effective in their role, while also starting to mentor others in ways to work efficiently.

Knowledge Assessment for Individual Contributors

* Models a culture of efficiency within the team where people make good, timely decisions using available data and assessing multiple alternatives

* Models using boring solutions for increasing the speed of innovation for our organisation and product

Knowledge Assessment for Individual Contributors

* Takes ownership of own team process inefficiencies, implements cross team efforts in ensuring things are running smoothly

Implements a way of working in the team where team members first search for their own answers and, if an answer is not readily found or the answer is not clear, ask in public as we all should have a low level of shame