Operations ·
Build a technology plan around business decisions
A useful technology plan explains what the business should do next, what can wait and who is responsible. A list of tools alone cannot answer those questions.
Read article →Notes from Norwind
Look closer at
the work.
Practical notes on software, engineering teams and the work a business depends on.
Operations ·
Make field records usable by the office
Information collected on a job is useful only if the next team can find and interpret it. Design the record around the handoff as well as the person entering it.
Read article →Operations ·
Questions to ask before commissioning software
A clear buying conversation connects the business problem to scope, ownership and ongoing operation. Use these questions to make proposals easier to compare.
Read article →Operations ·
Treat repeated status requests as a workflow signal
When customers and colleagues keep asking where a job stands, the missing piece may be a shared record of progress. Start with what they need to know to act.
Read article →Engineering ·
Keep control of the accounts your software depends on
A software handover involves more than source files. The business needs a clear route to its repositories, infrastructure, domains and operating instructions.
Read article →Engineering ·
Use the demo to test a decision
A working demonstration can make an idea concrete. It becomes more useful when the audience knows what they are being asked to judge and what remains outside the demonstration.
Read article →Engineering ·
When a customer integration blocks the next step
A requested integration can involve product scope, customer commitments and technical ownership at once. Clarify those boundaries before treating it as another connector.
Read article →Operations ·
Close the gap between completed work and an invoice
Delivery and finance need a shared account of what was completed and what can be billed. A handoff built from scattered messages makes both jobs harder.
Read article →Engineering ·
Make the first engineering task a test of onboarding
A small first task can reveal whether a new engineer has the access, context and feedback needed to contribute. Treat the obstacles as information about the team.
Read article →Operations ·
Find the delay between a request and a quote
A quote can wait in several places before anyone starts pricing it. Follow the handoffs to find the change that would help a buyer get an answer.
Read article →Engineering ·
Define what done means before the build starts
A shared definition of completion connects a feature to the task it must support. Include user behavior, failure handling and the way acceptance will be checked.
Read article →Operations ·
Make the process clear before automating it
Automation repeats the rules it is given. Review the purpose, inputs and exceptions of a step before making it happen without a person.
Read article →Operations ·
When dashboards disagree, define the metric first
Different numbers can come from different definitions rather than broken calculations. Agree the business event, population and time window before debating a result.
Read article →Engineering ·
Choose a software stack the next team can understand
Technology choices affect who can maintain an application later. Familiar tools help, but a maintainable system also needs clear structure and operating knowledge.
Read article →Operations ·
Replace “ask the expert” with usable operating knowledge
A system should remain understandable when its usual expert is unavailable. Start with the tasks another person would need to perform safely.
Read article →Engineering ·
Find the constraint before adding engineers
Additional engineers help when engineering capacity is the constraint. First check whether work is waiting for decisions, access, review or implementation.
Read article →Operations ·
A feature request deserves a question before it becomes a button
A useful internal tool helps someone finish a task. Evaluate a requested feature against the work it supports before adding another control.
Read article →Operations ·
Write project updates that help someone decide
A status report should make the work easier to understand. Replace broad descriptions of progress with evidence, uncertainty and the next decision.
Read article →Operations ·
When a temporary workaround becomes part of the business
A workaround needs attention when other people depend on it. Review its purpose, ownership and failure points before deciding to replace it.
Read article →Operations ·
Write down who approves access before the next hire starts
When every access request ends on the founder's desk, onboarding waits and departures go unchecked. Name the approver, the administrator and the review step.
Read article →Operations ·
When a meeting can become a written update
A recurring meeting should have a clear job. Separate information sharing from decisions that genuinely need people in the same conversation.
Read article →Operations ·
Watch the work before writing the requirements
A useful software brief starts with a real task. Watch where information is copied, decisions wait and people work around the official process.
Read article →Tell us what you
are building.
Or what is in the way. We will tell you plainly what it needs, whether that is us or not.
- 01A reply from a person
- 02A free half-hour call with an engineer
- 03A written answer: scope, rough cost, where to start
Replies come from a person, within two working days.