BE A VIKING.
Explore boldly. Deliver with discipline. Build what lasts.
Be a Viking is a modern engineering philosophy for people who take ownership, question assumptions, care about their craft, and make the whole crew stronger.
We build useful software. We also build the capability to do it again—with clearer judgment, better systems, and more trust.
WHAT WE BELIEVE
Good engineering changes more than the software. It changes what a team understands, what a customer can accomplish, and what becomes possible next.
A crowded backlog and a busy team do not tell us whether anything important became better.
Repeated friction deserves an engineering response. Better systems make good work easier to repeat.
Evidence earns confidence. Assumptions stay visible until they have been tested.
Responsibility works when people understand the outcome and have room to act.
The consequence of being wrong should shape how we make the decision.
Trust grows through honest commitments, sound judgment, and systems people can rely on.
Credit includes the work that prevents trouble, transfers knowledge, and helps someone else succeed.
Working software matters. So does what remains after the people who built it move on.
Strength is the ability to act decisively, adapt intelligently, and leave people and systems more capable.
THE PHILOSOPHY
Every team has a longship: the combined capability that carries an idea into dependable use.
Its hull is architecture. Its equipment includes environments, delivery systems, automated checks, and observability. Its charts are shared knowledge. Its strength comes from people who can work together without depending on constant rescue.
Name the outcome and the people it should help.
Keep the system understandable, dependable, and changeable.
Make controlled delivery and recovery part of the work.
Share enough context for someone else to continue.
Make actual behavior, failures, and recovery visible.
Bring different disciplines into decisions early.
Deliver value today in a way that increases your ability to deliver tomorrow.
When delivery is difficult, examine what makes the work unnecessarily hard. Repeated setup problems, fragile releases, missing knowledge, and unreliable checks consume the crew’s attention.
Invest in the foundation that the next useful outcome needs. Expand it when real work demonstrates the need.
Put it into practice Fix the recurring obstacle. Make the improvement available to everyone.
Start with a problem, a beneficiary, and a reason to act now. A worthwhile destination may be a simpler workflow, a safer system, an accessible experience, or a dependency that no longer blocks the team.
Speed becomes useful when the destination deserves the effort.
Put it into practice Name what should become better, for whom, and how you will recognize it.
Separate what you know from what you assume. Use a customer conversation, code inspection, prototype, behavioral test, or production measurement to answer the question that matters.
The depth of investigation should match the consequence of being wrong.
Put it into practice Test the assumption most likely to invalidate the next investment.
Expertise is valuable. Permanent dependence on one person’s availability makes everyone vulnerable.
Solve the difficult problem, then make the solution understandable, operable, and maintainable by others.
Put it into practice Leave enough knowledge for someone else to continue with confidence.
Make reversible decisions close to the work. Give consequential decisions proportionate scrutiny.
Before a risky change, understand how failure will be detected and what recovery requires. Recovery may mean rollback, restoration, reconciliation, or a forward correction.
Put it into practice Reduce the scope of the bet until the team can make it responsibly.
Useful work should leave something behind: clearer domain knowledge, simpler architecture, a better check, an operational playbook, or a colleague who can now act independently.
Sometimes the most valuable legacy is a dependency removed or an abstraction never built.
Put it into practice Deliver the outcome and make the next outcome more attainable.
THE AMBITION
A method can organize work. People also need reasons to care: useful achievement, fair reward, room to decide, opportunities to grow, and a sense that their contribution matters.
Celebrate the prevented incident, the removed complication, the colleague who became independent, and the feature you discovered nobody needed.
HOW THE WORK MOVES
An expedition is a bounded effort toward a worthwhile outcome. It might be a feature, a migration, a reliability improvement, or an experiment.
VIKING gives that work six connected activities. Revisit them as evidence changes. Several may happen together.
Venture + Investigate Should we go, and where?
Kit + Implement Are we equipped, and can we deliver?
Navigate + Ground Is it working, and can it last?
Revisit the activities as evidence changes. Several may happen together.
01 / 06
Choose a worthwhile outcome. Bound the investment.
Name the problem, the people affected, and the improvement you want to make. Establish an owner and decide how much to invest before reviewing the evidence.
Separate a delivery commitment from an outcome hypothesis. You can commit to running an experiment; you cannot guarantee how people will respond.
02 / 06
Understand the terrain before committing heavily.
Study the real workflow, domain rules, existing behavior, dependencies, constraints, and failure modes. Record the source of important findings and keep unresolved assumptions visible.
Investigate until you can make the next responsible decision. You do not need to describe the entire organization.
03 / 06
Equip the crew for the work ahead.
Establish the minimum architecture, environments, access, automated checks, delivery controls, and observability needed for this outcome.
Agree on acceptance evidence and a credible recovery approach. Build foundations for demonstrated needs.
04 / 06
Complete the smallest useful result.
Deliver a narrow, complete workflow that someone can actually use. Include the necessary validation, permissions, error handling, and operational visibility.
Keep work in progress within the crew’s capacity to finish and evaluate it.
05 / 06
Compare reality with intent. Adjust the course.
Examine whether the result works responsibly and whether it creates the intended value. Use actual behavior, user feedback, reliability, cost, and the evidence agreed at the start.
Decide explicitly whether to continue, change, expand, pause, or stop. Useful learning resolves a named uncertainty and changes a decision.
06 / 06
Give the result a durable home.
Confirm ownership, operating expectations, documentation, support, and known limitations. Transfer the knowledge required to maintain and extend the work.
Retire superseded paths when the necessary checks support it. If the experiment stops, remove temporary exposure and infrastructure, preserve useful findings, and close it cleanly.
YOUR PLACE IN THE CREW
Every role sees something the others might miss. The work becomes stronger when those perspectives shape the decision early.
Titles vary. Responsibilities still need to be clear.
01 / 07
Make the behavior correct, the design understandable, and the system changeable. Deliver complete slices and make technical trade-offs visible.
Will another engineer be able to understand and safely change this?
02 / 07
Connect the work to a worthwhile problem. Make priorities and outcome hypotheses explicit. Help the crew decide what deserves the next investment.
What evidence would make us change the plan?
03 / 07
Bring the real experience into the room. Make workflows understandable, test assumptions, and ensure people with different needs can use what we build.
Does this help someone complete the task in their actual circumstances?
04 / 07
Expose consequential failure modes, clarify acceptance evidence, and improve the team’s ability to detect problems throughout delivery.
What could appear to work while still letting someone down?
05 / 07
Make safe delivery and dependable operation easier. Reduce recurring friction, strengthen observability, and help the team recover.
Can the crew operate this confidently when conditions change?
06 / 07
Make threats, access boundaries, and data responsibilities understandable. Help the crew choose proportionate controls while the design can still change.
Who could be harmed, and what prevents that?
07 / 07
Clarify the destination, resolve trade-offs, develop decision-makers, and protect the conditions for sustainable work.
Does the team have the clarity and authority to act without waiting for me?
Responsibilities can overlap. Accountability should remain explicit.
HOW WE LEAD
Leadership makes good decisions possible beyond the leader’s immediate reach. It provides direction, creates workable conditions, and strengthens the people who carry the work forward.
Explain the destination, priorities, constraints, and trade-offs. Give people decision rights that match their responsibilities.
Reflection Have I provided enough clarity for a capable person to decide without me?
Make promises carefully. Surface uncertainty early. Explain consequential decisions and update them when the evidence changes.
Reflection Can I defend this decision through its reasoning rather than my title?
Expect people to challenge assumptions and raise concerns. Meet early bad news with curiosity and action.
Reflection What might people know but hesitate to tell me?
When a plan repeatedly requires exceptional hours, reconsider scope, staffing, sequencing, or commitments. After a crisis, make room for recovery and prevention.
Reflection Does this plan depend on capability or repeated personal sacrifice?
Recognize visible and invisible contributions. Examine leadership decisions and system conditions alongside individual actions.
Reflection Am I developing capable decision-makers?
Agree on stopping conditions early. Previous investment and personal attachment do not justify the next investment.
Reflection Knowing what we know now, would we choose to continue?
POWERFUL TOOLS. CLEAR RESPONSIBILITY.
AI can support discovery, implementation, testing, documentation, and bounded operational work. Its usefulness depends on clear assignments, appropriate access, and evidence that the result meets the need.
A named human remains accountable for the initiative. Routine actions can proceed within established boundaries; consequential exceptions deserve deliberate review.
Generated code and generated tests are artifacts to evaluate. Agreement between them is not sufficient proof of correctness.
Useful autonomy is autonomy the crew can understand, verify, and trust.
EVIDENCE OVER ACTIVITY
Use a balanced set of questions to understand the work. Look for patterns that help the crew improve.
Lines of code, tickets closed, hours worked, and agent activity describe activity. Use measures to investigate and improve the system. Do not turn them into rankings of individual worth.
THE FIELD GUIDE
You do not need a transformation program to begin. Choose a bounded piece of work. Make the outcome clear, expose the important uncertainty, and agree on the evidence that will guide the next decision.
Example expedition — Improve order entry (illustrative)
A short outcome-and-risk review can keep the brief useful. Update it when evidence changes the decision.
BE A VIKING.
Build something useful. Make it understandable. Help someone else become more capable.
That is work worth being known for.
