Introduction

Introduction
Strategy
Goals
Responsibilities
- General
- Permission Management
  - Background
  - Principles
Roles
Tools
Core processes
People operations
Support processes

Background

We aim to be"transparent by default". We want to be equally transparent to clients and our team - both current and future. Hence the open-source nature of this document.

We also want to be an active part of the remote-work community and want to share what we've learned with other startups to bring the wonders of working as a distributed team to the world.

Update the handbook

Feel free to ask questions through issues and contribute by creating merge requests. When creating an issue, use a link to the line you are referring to for easy access, i.e. https://gitlab.com/stanwood/handbook/blob/master/mission.md#L5.

Make sure to update the TOC after you added or edited headlines.

Strategy

Mission

Stanwood exists to develop

people - to become their best self
teams - high performing and trusting
digital products - that are useful and have impact

in that order.

We want to revolutionize how agencies operate.

Typical Agency	Our aspiration
Focus: Profit	Focus: People & teams
Excellence: Process design and efficiency	Excellence: People operations
Recruiting: Expendable ressources	Recruiting: Only hire the perfect fit that raises the team
Location: In hubs	100% distributed

Professional conduct

I. Enthusiasm & fun personality

We are fun to work with (wink)

We are outgoing, confident, charming, helpful and honest.

We communicate openly and in a timely manner.

We are not shy, hide in slack or keep grudges.

II. Time-to-market focus

We focus on shipping stuff to our client and their users.

We are super efficient.

We prefer building things over having meetings.

III. App quality

We produce fantastic user experiences.

Beautiful UI
Easy to use
Rock stable
Super fast

IV. Strong architecture and clean code

We standardise our architecture to enable fast project switching.

We actively propose changes to our standard architecture.

We write clean code. That includes

Separation of Concerns
Dependency Injection
Single Responsibility Principle (but not strictly adhered to)
Testable Code
Short functions - should be visible on the screen
Clear and understandable naming

Values

I. Transparency and openness

We believe that transparency in itself is a virtue. The more we act in the open, the less likely we are to fall victim to internal politics or mistrust.

We also want to enable potential clients and team members to know what they are facing.

Exceptions

Very private

Some documents are not made public and reside in the GDrive of the MD. These are:

All data considered "private" (under data protection regulations or other laws).
Contracts with freelancers and employees.

Internal

Some documents are only available to team members and not the public. They reside in databases, GDrive, Candis, Debitoor, Github or GitLab. These being:

Production client data - only accessible by admins.
Client contracts and offers.
Slack conversations - except direct messages or confidential discussions in #leads_private - we strive to discuss typically confidential topics in the open.
Code and tickets on non-open-source projects
Passwords and production keys (they are in 1Password).

Openness and honesty

We prefer the hard truth over mollycoddling. However, you can tell even a hard truth kindly.

We embrace numbers and data over gut feelings or single experiences.

However, we also know, that data is only a small part of the truth.

We do not misuse numbers. We know they are biased and need interpretation.

Failure

Human beings made mistakes in all of history. We are living in a world of imperfect information. We also know, that we are biased - especially when it comes to people. We therefore act on the assumption that 90% of our decisions are wrong.

We try to fail often and fast.

Failure is the best way to learn.

We admit failures - even brag about them.

Language

stanwood is a (UK) English speaking company.

Except for very few, English is not our first language and quite frankly, we could use a bit of work on that.

All written and oral communication must be in English. Yes, even between countrymen.

We try to avoid abbreviations and industry speak as much as possible so that anyone can understand our writing. Only use jargon, if there is no equivalent in everyday English. That also helps us not to come across as pompous ;-)

We always refer to employees and freelancers as "team members" or "Woodies". New Woodies are called "Wookies" (Rooke + Woodie).

When talking about people we use the plural to avoid female or male pronouns and we try to use neutral terms where-ever possible. If not possible we alternate between female and male pronouns.

II. Hacker mindset

We work smart:

Automate everything.

Reuse existing solutions.

Do not reinvent the wheel.

We work super efficiently.

We understand the 80/20-rule.

We continuously review our tools and processes.

We believe in teamwork.

Results and time to market is far more valuable than personal credit.

III. Constant change

We always try to improve ourselves and others.

We always try to improve our processes and policies: They should help, not hamper.

We are open to new suggestions and improvements.

We try out new things early and often.

IV. Ownership

We take personal responsibility for our products.

If you find something that is broken, we make sure you fix it.

If someone must do something, we pound them into action - repeatedly.

We take personal responsibility for our tasks.

We never ignore an email or post when someone uses our handle.

We acknowledge questions or tasks within 1h in Slack or in 24h in an email.

If we cannot complete it right away, we give an ETA.

Should we not be able to hold that ETA, we inform the other with a new ETA as soon as possible.

We test and iterate our output and our processes as often as possible.

III. Love it, leave it or change it

We are hackers - we do own things the best we can despite imperfections of the outside world.

Instead of complaining, we focus on what we can control.

IV. Respect, Friendship and Support

We conduct ourselves friendly, respectfully and helpfully at all times.

But we are no family. Families exist to further relationship. stanwood exists to further our vision and strategy. Even though we strive to have the best of relationships, we let individuals go, if the are detrimental the company.

Unless someone falls on hard times: sickness, personal problems, financial issues. In those cases, we support.

We also believe in second changes and developing people. A failure in a project is never grounds for termination. Even if somebody currently does not share our vision, strategy or is not embracing our values: We do not let people go lightly. Hiring and developing teams and people is a time consuming and cost intensive process. But we also want to foster a work environment where people feel save to speak up and fail by trying out new things.

Instead we review, feedback, mentor and give second chances. Even if we decide to let somebody go, we help people we let go to find a new job and cushion the financial impact of a termination.

We embrace diversity: Nationality, language, religion, gender, sexual orientation, disabilities or mental health. We cannot have it colourful enough.

We don't disclose what someone tells us in trust.

We support each other wherever we can.

We do not allow harassment or discrimination based on age, disability, race, nationality, religious belief or lack thereof, life expectancy, sex, sexual orientation, transgender status.

We do not tolerate violent acts, threats or encouragement of violence, fighting, bullying, coercion or use of abusive or threatening words, directed to, about or against a team member, client or third party, even in a joking manner. First-time violations of this value is a fireable offence.

We kindly nudge each other should we, for instance, use the male form of a word by adding the eggplant emoji to the post.

V. Working remotely

We work where we can work best: near our families and at the places we choose, because we want to, not because we have to.

We treat each other the same - despite our location.

Working remotely can be a challenge: When someone annoys us, we assume ignorance before bad intentions.

Make an extra effort at communication.

We want to be able to work whenever, where-ever and how much we want. Towards that end we build our processes around asynchronous work, document everything and try to avoid the need for real-time communication and collaboration.

We do not discriminate based on the locations chosen by our team members. We pay the same whether you live in London or Bangkok. However, that also means, that we do not pay for travel time or cost over an average travel within Europe.

Goals

We employ the OKR goal system invented at Intel and popularised by Google by John Doerr.

To read more on the process and background on goal setting, read Measure what Matters

Company OKRs 2020

Objective 1: Sustainable growth

Key result: Total quotes sent out > 6 m€ @sales
Key result: Profitability > 30% EBIT margin @dev_teams @pms

Objective 2: Delight clients

Key result: Customer satisfaction > 90% (NPS) @pms
Key result: Sprint burn-down* > 90% @squads
Key result: Production/client reported bugs < 1% of total tickets @squads

Objective: 3. Become the authority on digital business and remote work

Key result: 200 social posts @karinkleist
Key result: 12 presentations held at events @hanneskl

Objective 4: Calm our operations

Key result: Nobody reports having being stressed very often or often in the stress survey @hanneskl
Key result: Reduce the number of Toggl tasks / hour to 40 @hanneskl
Key result: 100% of the company working < 40 h / week (including Hannes)

Squad OKRs

Objective 1: Profitability

Key result 1: Project profit margin > 60%, squad profit margin > 50%
Key result 2: # of stories > 320 @hannes
Key result 3: Tickets in Ready for Development/current_sprint > 30 h / dev
Key result 4: Maintenance contracts with all clients EOY
Key result 5: Sprint-based contracts with all clients for feature development EOY

Objective 2: Reliability & Quality

Key result 1: Sprint burn-down* > 90 %
Key result 2: Production/client reported bugs < 1% of total tickets
Key result 3: Crash production apps latest version < 0.5%

Objective 3: Become one team with the client

Key result 1: Responded to client mails on average within 12h as measured via intercom
Key result 2: 100% of client's project owner participates in dailies as reported by scrum masters via a weekly slack bot. @marcin

Platform OKRs

Objective 1: Build an eight A-level dev rooster

Key result 1: Performance rating of 2 for 100% team members
Key result 2: Create a skill matrix and assess all team members by March 1st
Key result 3: Create training plan to train each of the skills by by March 1st

Objective 2: Reliability & Quality

Key result 1: Sprint burn-down* > 90%
Key result 2: Production/client reported bugs < 0.5% of total tickets

Objective 3: Profitability

Key result 1: Platform profit margin > 40%

More than 90% of tickets (as counted in Ready for Development and Working on on Monday 02:00) in Done on Friday 02:00

Responsibilities

General

We need to have clear policies on

who can decide things
who needs to be asked for advice
who should propose

Of course, we always strive to involve everyone in all discussions.

Topic	Init	Advice	Decide	Implement
PLANNING
Strategy	Head of biz dev	Everyone	Owners	Squad
Values	Managing director	Everyone	Managing director	Managing director
Revenue projection	Managing director	Squad	Managing director	-
Goal setting - Company & Squads	Managing director	Squad	Managing director	Squad
Goal setting - Woodie	Squad	Everyone	Squad	Everyone
Budgets	Managing director	Squad, Platform	Squad/Managing director*	-
POLICY
Development process	Platform	Squad	Platform	Platform
Frameworks	Platform	-	Platform	Platform
Platform architecture	Platform	-	Platform	Platform
Security	Head of tools*	Platform	Managing director	Head of tools
Workshops	Platform/Squad	Everyone	Managing director	Platform/Squad
System architetcture	Platform	Squad	Managing director	Platform
Communication - Squad	Squad	Managing director	Squad	Squad
Communication - Policy	Everyone	Squad	Managing director*	Managing director
Travel	Managing director	Squad/Platform	Managing director	Everyone/Assistant
Marketing	Head of marketing	Platform/Head of sales*	Managing director	Marketing
Customer relations	Head of sales/Platform*	Platform/Head of sales*	Squad	Squad
Alumni	Managing director	Platform	Managing director	Platform
PEOPLE OPS
New squad creation	Managing director/Squad*	Advise Squad/Platform	Managing director	New squad
Recruiting	Squad	Platform	People Ops Committee	Platform
Onboarding	Platform/Squad	Platform/Squad	Platform/Squad	Platform/Squad
Personal development	Squad	Everyone*	Squad	Squad
Performance management	People Ops Committee	-	People Ops Committee	Squad
Compensation	Platform	Squad	Managing director	Managing director
Promotions	People Ops Committee	-	People Ops Committee	Managing director/Squad
Trainings	Platform	-	Platform	Everyone
Transfer	Squad	-	Squad	Squad
Termination	People Ops Committee	-	People Ops Committee	Managing director
OPS
Workshop Organisation - Company	Managing director	Squad	Managing director	Karin & Squad
Workshop Organisation - Platform	Platform	Squad	Platform	Platform
Workshop Organisation - Squad	Squad	Platform	Squad	Squad
Assigning projects to squads	Managing director	Squad	Squad leads	Squad
Project planing	Squad	-	Squad	Squad
Utilization	Squad	-	Squad	Squad
Project staffing	Squad	-	Squad	Squad
Project management process	Squad	Platform	Squad	Squad
Product documentation	Squad	-	Squad	Squad
Communication tools	Squad	Managing director	Squad	Squad
Corporate tools	Managing director	Squad*	Managing director	Managing director
Freelancer invoicing	Squad	-	Squad	Squad
Time tracking	Squad	-	Managing director	Squad
Sales	Head of sales/Platform*	Platform/Head of sales*	Managing director	Richard
Admin	Managing director	Managing director/Squad	Managing director	Managing director/Squad

Permission Management

Background

We are facing four opposing principles when it comes to permissions.

Transparency and openness by default: Every team member should be able to read and change anything.
CD/CI: We need to save guard against breaking our continuous integration and deployment or production environments.
Data protection: Private end-user data (databases, logs etc.) should be visible only to the smallest amount of people.
We do not want a bottleneck on permissions should an admin be not available.

Principles

Data protection: Production data needs to be limited to the least amount of people possible and reviewed regularly.
Code and documentation: Every team member has read permissions.
Our Head of Automation closely guards writing-permissions.
Contact the Head of Automation in #operations in Slack if you need more permissions.
Every admin permission should be with three people: MD, Head of backend development, Head of Automation.

Roles

Leadership

Background on leadership

When choosing managers we consider a bunch of criteria - based on quantitative research by universities and how successful startups select and develop managers.

In particular, we are inspired by Google. Apart from being one of the most successful companies in the world, they are consistently ranked the best-place-to-work by her employees. Their mixture of employee empowerment, influences from the Montessori of Larry and Sergey and the reliance on the latest research and - of course - loads and loads of their own data truly matches our own values.

Leadership criteria

Empathy: Can the lead consider the perspective and situation of the other person.
Humbleness: 90% of our decisions are wrong. Act the part!
Ownership: A lead sees a problem and makes it her own until it's fixed.
Leadership: "Every success is due to the team, every failure is mine." and generally leading by example.
Cognitive abilities: We just love people who are smarter than us. So much to learn...
Grid: Only the hard stuff is worth doing.
Communication: Running a remote team is x10 as hard as in an office. Exceptional communication skills (verbally, written and non-verbally) are key.

Technical skills to become a leader

We do not consider technical skills to be awfully important.

We do not promote the best "screwdriver" to run team "screwdriver". Our leads are tasked with helping the Woodies to grow as a person, becoming an entrepreneur, an amazing team member and generally an awesome human being. They shall also make the team perform better and reduce stress.

We hire only the smartest, most dedicated and fun people* and want to empower them as much as possible.

Promoting on tech skills alone will achieve exactly the opposite. With the best (i.e. Python) coder managing a team, the members would too often refer to the lead instead of making their own decisions. This inevitably leads to micromanagement and a hierarchical corporate structure.

Actually we want to turn the traditional hierarchy on its head. I wanna be the dumbest person. So we only hire people who are smarter or more experienced than the person who is hiring. If you doubt that, ask @paddy about the original ObjC code in ON AIR and Glamour.

Train your successor

One of the key responsibilities of leaders at stanwood is to ensure that we will always have leaders on all levels.

Because a leader might leave the company or switch to another role, the first priority for a leader is to have two members of his team which he grooms into becoming leaders themselves.

Team lead

Philosophy

Leadership means: "Take the blame, share the fame."

As a leader, everything is always your fault. So you should still take actions to fix situations.

Examples:

if one of your team members is unhappy or not performing
if a client or project manager is unresponsive, unclear in his briefings or confused
if a project is not running well
if the MD is a tyrant

As a leader, you are only a facilitator. Your team does the actual work and deserves all praise.

Lead by example

Demonstrate our values, policies and processes every day
Push back on poorly described tickets and complex solutions

Responsibilities

Improve the company

Proactively identify processes and policies that need improvement and push for change
Help the other people and leads to improve their team's procedures and policies
Analyse data to find patterns in our work

Recruiting

Define developer recruitments standards
Interview and recruit new developers
Push the applicants through the process

Staffing

Coordinate project roster
Make sure the team is well mixed and get the chance to work with everyone.
Navigate and support project leads to ongoing projects.

Technology

Push the boundaries of your platform OS capabilities
Find a team member per framework and make the evangelists
Define and improve the company's system architecture
Liaison with the other platforms to align practices

People development

Oversee team development, and policy implementation
Propose promotions and developers who need review
Prepare and establish quarterly team review

Training

Plan, organise and manage 3 annual workshops
Develop individualised training per team member
Work alongside the PM's to utilise the best working environment

Personal support

Support the team with any issues they have, and identify strength and weakness
Develop career plans for every team member

Project lead

Project leads oversee the project development, are the direct contact for PM's and manages the team to meet best coding practice, release dates, and budget.

Responsibilities

Application Architecture

Propose alternative and simpler solutions, even if they do not meet 100% of requirements. Clients often accept such tradeoffs.
Ensure Stanwood architecture is used to reuse code and limit complexity
Code review to ensure code quality

Project planning

Make sure the ticket's description is sufficient to start development, for example:
Check if designs are provided
Check if Backend is available
In case of a bug, tickets check if there is sufficient data to start bug fixing like Crashlytics link, steps to replicate, info about the device
Check if tickets scope is not too large and break it down into sub tickets. A good rule of the thumb to ensure ticket estimate is not over 4h
Assign tickets to your peers to ensure optimal workload and highest chances to complete tasks on time
Review tickets estimations to make sure it is realistic. Not overinflated or too optimistic
Review and agree with PM scope of work and timelines, especially important milestones like app release.

Project execution

During project execution, you are a single point of contact for a PM for your platform. It means:

Proactively communicate project progress as required by PM.
As soon as you are aware of any new risks for project schedule, cost or quality inform PM and propose mitigation steps.

Application Documentation

Make sure 1password has all used secrets and password for the project.
Update slack channels with necessary information
Maintain project readme

Code review

Making sure code review is done by stanwood best practice and follow the guidelines. PR/CR Guidelines

Senior developer

As Senior developers, you have significant experience in software development, knowledge of industry practices and you are the backbone of software development at stanwood.

Responsibilities

Liaise with project leads
Implement stanwood architecture
Design and implement new features
Push back on features that add complexity
Ongoing bug fixes, and maintenance
Keep project documentation up to date
Maintain and manage the existing code base
Liaise with project leads on new deadlines and new features

Design and implement new features

As a senior developer, you do most of the heavy lifting during development.

Push back on features that add complexity to the project lead. We are not here to solve every client feature request but look for the quickest, and safest solution that supports the code base.

Ongoing bug fixes, and maintenance

Keep project documentation up to date Work alongside the project lead and update the documentation on a regular basis.

Maintain and manage the existing code base

Make sure we are not adding technical debt when maintaining the code base. Should there be a case where the current code base does not support ongoing development, involve the project-lead?

Project managers

Order of priorities:

1. Client Communication

Keep the client close

Keep client informed about progress, spent budget and blockers 3x per week.
Send at least one personal mail a week.
React on average within 15 minutes to calls.*
React on average within 2 hours to emails, but always aim to be faster.* A short "we are on it, I will get back to you" is ok, but aim for client satisfaction.
React to all client requests in 1 workday.
Use hubspot to log all client communication (gmail connection or extension with bcc) see
Create tickets to all issues raised within one day.*
For client raised tickets, add the label reported_by_client to any bug, that the clients caught (on stage or production) or bugs we find on production.

During business hours.

Measure client satisfaction and improve

For all A-Level sprints:

Update all hubspot client properties for satisfaction once a week:
Update the CSAT Rating (subjective)
After each major release, ask the client to rate us with the NPS score (form)

2. Jira/gitlab Hygiene

Once a day:

Zero the inbox
Ping the project leads to estimate if the ticket has not been updated within the last working day
Ping the assignee if if ticket has not been updated for more than 1 week.
Ensure:
- tickets are well described
- documentation regarding that ticket is up to date
- everything discussed in Slack is synced back to Jira/gitlab

3. Internal communication

Offer a PM office hour for all devs 2x a day: 10am, 4pm in stanwood.appear.in/yourname. Post that to slack.
All project questions should get cleared in this call: minimize project chatter outside these hours. Exeptions: a) Friday for building and submitting (everything goes), b) emergencies
Keep your lead and all devs up to date of milestones, next milestones, of the pressing issues, blockers and goals 3x per week.
Send an update post for all your projects in slack channel #done friday noon until 12:00am. Keep the post numbered and think about it as a logbook.
For every project include status, blockers, next milestones
is there a sprint in the following week, also include
- if the sprint planning call took place,
- how many hours are in the backlog for that sprint
- and which teams attended the planning call(s) (client, dev-teams, qa).

4. Sprint steering

At least every Thursday before the sprint: Grab the client and your team (including QA) and fill the backlog of the team according to the sprint planing spreadsheet. Separate calls with client if it makes no sense to have a big round with all devs.
Make sure all tickets are well described before the sprint starts. All Devs should be able to work on it without further questions.
After ticket creation: Tickets go to QA to add acceptance criteria, then to estimation to Dev.
Wednesday: Check the burndown of the sprint, should be more than 50%
Make sure the sprint burndown reaches 100% at Thursday, 23:59 CET

5. Make sure we hit 50% project profitability

Check the budget with all toggl logged hours every week.
Alarm your lead and team if your projects wents lower than 50% profitability rate (check the PM dashboard), and if non-coding work gets higher than 40%.
Push back unreasonable and complex features. Alert Hannes, if you need firepower.
Do not start before:
1. Offer send & client signed budget
2. Designs and Specifications
3. Mock API from us
4. Kick off with team & client

6. Keep documentation and Zeplin up to date

6. Upselling

Suggest features and improvements to clients. Don't sell unnecessary stuff: Offer and delight. We are inbound, not outbound.

Tools

Zeplin

Background

We use Zeplin to share and discuss designs and also to host design assets and documentation for the developers.

Guidelines

Designers: Upload files there and puts sketch file on GDrive
Tickets live in Jira. However, only for briefing and status.
Commenting happens in Zeplin
- Yellow: Todo
- Orange: Discussion
- Green: Documentation
Upload a photo and a profile picture to Zeplin.
Use the same handle as in slack.

Toggl

Background

We currently pay our freelancers and invoice our customers on an hourly rate and use Toggl to track time.

Guidelines

Let's go through the different projectsunder which you can track time. There are four main topics around which you can track time:

Work for clients,
Stanwood related work
Squad related work
Platform related work (IOS, Android, ...)

1. Project based

For each client based project, we have 7 standard categories for time tracking.

Client communication is mainly used by project managers it involves everything around communicating with clients: Workshops, Client meetings, calls, ...
Deployment is time spent getting the app live: writing App Store descriptions, ...
Internal communication is time spend discussing with the team: office hours, Slack, ...
QA is mostly used by the QA team and is everything that evolves around testing the app: smoke tests, general QA work, ...
Test agency is used by the QA when they review the feedback received from our test agency
Ticket review is time spent writing tickets, editing them, ... It is mainly used by project managers.

2. General Stanwood

For general company related tasks, we use the admin project which contains 6 categories:

Accounting is mostly used by the MD
Invoicing is for sending invoices. It is mainly used by the MD.
Strategy is mainly used by leads for discussions about the company's strategy
Zero inbox is mainly used by the MD or leads
Travelis only used by the MD to get a better understanding of how he spends his time.

Then, we have a few more categories that are Stanwood related

Marketing is for everything around content creation: social media posts, article writing, ...
Internal Workshops is time spent in team workshops
Recruiting is used for time spent interviewing candidates, replying to their emails, ...
Sales is used for time spend optimizing our sales funnel, communication with leads, ... anything that can help us get new customers
Training is for time spent learning a new skill: Udemy courses, masterclasses, ...

3. Squad related

Squad related tasks are the following:

Admin is for general administrative tasks related to the squad, mainly used by the squad lead.
Admin - Onboarding is used by Wookies (new employees/freelancers) during their first weeks for all the things they can't categorize: setting up accounts, ...
People Operations is for tasks like recruiting or other HR related work. It's also mainly used by the squad lead
Squad Meetings & Workshops is for all the meetings, calls & workshops that are Squad related. The weekly planning call for example.
Out of work / Nothing to do has been introduced recently and is to be used by people who have minimum monthly hours but no work to do - it does not apply to most employees.

4. Platform related

We have 5 platforms at Stanwood: IOS, Android, Web, Backend& Project Management. For each of these platforms there are three subprojects under which you can track time:

Frameworks is for work on frameworks.
Trainingis for courses, masterclasses or anything you are doing to sharpen your skills for the job
Workshops & Meetingsis for all platform related meetings and workshops.

The distinction between Platform work, Squad work or Stanwood work can sometimes be a bit confusing. If you have any doubts, always ask someone. Some subprojects have the same name (Admin for ex.): check the prefix to verify under which project you are tracking:

SQ0 is for Stanwood SQ1, SQ2 & SQ3 is for Squads

Slack

Background

We use slack as our daily real-time communication tool for projects and our central non-project communication.

Profile

Add a full name, picture, phone number and email.

Username: @firstname, if taken @nickname

Same on every other platform that we use.

Channels

#general

Official stuff. Only the MD posts here.

#status

Post "Good morning", "be-right-back", "back", "good night" + what are you going to do today. Post "off" when you are leaving.

The first line of your post and the first emoji becomes your profile status message. Use it to communicate your availability to people who try to reach you.

When leaving for vacation, please use this template: :desert_island: on vacation, back at August 23rd.

#random

GIFs, cat videos etc. to

#programming_X

General programming talks and ask for help

#project_management

General project management and ask for help

#done

PMs post status updates for all their projects on Friday before 12:00 CET. See PM internal communication for guideline.

Tackleberry

Our very own police bot to send you reminders that require your actions from time to time.

Tickets that need your estimation
Tickets that need to be moved
Tickets that have are already 50% over estimate: Update the Remaining estimate and inform your pm
Tickets that have are already 100% over estimate: Update the Remaining estimate and inform your pm

Guidelines

Responding

When responding to todos in slack, open a thread, use "On it {time}" (i.e. "On it in 1h") and "Done"/:white_check_mark:.
Whenever possible, use meaningful slack reactions instead of posting an reply (example: https://twitter.com/stanwood_apps/status/1094899597443518464)
Add the handle of the person you are responding in the thread.
One thread per question, don't mix up two questions in a thread without a clear differentiation (e.g. numbers).

Naming

Project channels starting with "_". All real-time discussion belongs there. Jira, Zeplin, Github, Bitrise post to the project channel.

Transparency

Please do not do project talk in direct messages. We lose that information to the company. Use a public channel instead. We are transparent by default, example:

When asking someone something, always use @username. Some developers are a member of dozens of channels and might miss your question.

Always use threads:

start your thread with a bold headline in the main channel to keep the channel clean
first line: add short one-line summary
add the handles of people you need to react with a clear CTA (e.g. FYI, acknowledge, review etc.) Example: https://twitter.com/stanwood_apps/status/1094220876600492032

What to use slack for

Posting FYI information
Asking questions
Assigning non-project todos
Fun and giggles
Short discussions (max five posts)

What NOT to use slack for

Real-time discussions: Jump on a call.
Async discussions: Use Jira
Async questions or todos (like asking someone who is on vacation more than 1 question per channel)

Sketch

Background

We use Sketch for designing all our apps and websites.

Naming convention

Digit 1: Epic
Digit 2: View
Digit 3: Variant

Example: 1.1.2 Onboarding - Welcome Screen - Disabled

Storage and file versioning

We store all sketch files in the Design. The "owner" of that folder is info@stanwood.de

Fileformat: {year}-{month}-{day} {project key} {project key} {description [optional]}.sketch´ as a file name. Example: 2019-04-15 TMB Timberbase.sketch´

Try putting all designs in one file.

GDrive has a version control. Do not create versions of the file on your own.

Wireframing

We only use the "2019-03-12 Material Design Library" for wireframing to ensure re-usability of wireframes.

Symbols and naming

Design files need the same thought and structure as code does to ensure that we can maintain and scale a design.

Guidelines

Your views should only have symbols in it.
At the end of a design session: Clean up your symbol page
- Ensure they are grouped together by topy
- Ensure proper naming with paths
- Set with elements are adjustable and which not
Do not create custom design elements in your file.
- Discuss with Hannes
- Put them into the central template
- Adjust the components page in the central template
Structure the view: 0,0 for the first view, 0,1000 for the second
Put iOS and Android side by side
Use themes and font styles

Form Design Guidelines

Forms tend to be overlooked but they are actually one of the most important part of any website or app since they are what we want users to interact with. Badly designed forms lead to high churn and bad user experiences.

Pay attention to the following:

How will the form look like on a small screens
How will the form look like with/without the keyboard
Differences between Android and IOS design guidelines for forms (i.e. date picker)
Only add absolutely essential stuff to forms (i. e. you don’t need a password reset button on the registration page)
Forms should be designed in a way, that all UI elements fit onto the screen (with the keyboard popped out). For longer forms, use multiple screens
Marketing double opt-in must always be optional (by law)
It’s fine to require the user to approve T&Cs and Privacy Policies.
Passwords should be plaintext by default with a "hide" button
The default action button (i.e. "Proceed" or "Sign up") should always float at the bottom, 100% width, with a super bright color and above the keyboard or the bottom of the screen
Use customized keyboards (i.e. numbers only for phone)
Always reward users after major steps i.e. “Well done for signing up!”. Don’t forget to design a screen or toast that feels good to look at.
Requesting users to sign up (even with a "skip button") in onboarding is dangerous and will generate a high churn rate. When possible, let users browse through the app without having to sign up.

Make sure to:

Design a large (iPhone X etc.) 375x812 and small (iPhone SE) 320x568 resolution
Design a large Android 360x720 and small 320x640 resolution
Design with and without popped out keyboard (example can be found here)
Use material design guidelines for text-fields
Add Google/Facebook sign up buttons on registration and login screens (don’t use text links but the actual logos as in the example)
Have buttons look disabled (grey or 50% alpha) until all requirements of a field are met (example can be found here)
Put the password field on a separate view and explicitly show the password requirements and make the font colour of the requirements red initially and green, as the user meets them (example can be found here)
Add a progress indicator visually and verbally describing the steps required. i.e. "Step 1/4" if there is more than
Design helpful error screens explaining the issue and what the user should do next (example can be found here)

Appear.in

Background

Appear.in is the tool we use for quick video calls with clients or team members. We also use it for Masterclasses as it allows us to record video calls.

How to use it

Simply sign up with your stanwood email

Uber/MyTaxi

Background

We use Uber & MyTaxi to book short trips if we want to work during the trip

How to use it

If you've not automatically received an invitation, ask the MD.
When you book a trip, make sure to have it billed under your Stanwood's account

Hubspot Sales/CRM

Background

We use Hubspot to transparently share client communications with the team, for recruiting and to schedule social media posts. Hubspot is also a powerful tool to track website visitors.
It is of crucial importance that you activate 2FA when using Hubspot.

Logging E-Mail conversations

Make sure you have hubspot sales access (free is ok)
Add your sending addresses to your email aliases under Profile & Preferences in Hubspot
Install the hubspot sales extension.
connect your gmail to hubspot or:
Sending: Activate Log and Track in the compose-view when sending Mails. If it's a known contact with GDPR consent, Hubspot will add the log to the contact. If you do not use chrome (e.g. if you answer on your phones mail app), use 4628060@bcc.hubspot.com
Receiving client communication: See 4: Connect your Gmail to hubspot. If you did not connect:_ If the client did not cc is to our sales address, the mail will not get logged. Forward unlogged mails to 4628060@forward.hubspot.com

Jira

Note: We experiment with gitlab at the moment for a complete replacement for jira.

Background

We use Jira as our central tool for organising our development process around tickets.

Types of Work

1. Epic

Group of tasks for a section in the app or topic.
Usually along the user flow in the app:
Design, Setup, Onboarding, Section 1, Section 2..., SDKs, Release
We try to finish epics in a development cycle so that the client and our testers can thoroughly review that block.
Tickets that the client actively decides not to implement or fix are assigned to the Version Later to hide them out of the backlog to keep the backlog relevant and up to date.
Each Epic has a link to the GitHub Documentation of that Epic.
Each Epic needs to have these elements: - Link to Zeplin designs - List of all UI elements - Where is the element getting its data? - Where is the aspect of writing it's data to -A list a and description of all interactions including view did appear - data was loaded successfully - an error occurred when loading the data
- all possible user interactions

2. Tasks

Tasks have a link to the GitHub documentation and Zeplin of that Task.

3. Sub-Tasks

Tasks are broken down by the project lead into Sub-Tasks.

Each task is assigned to one platform and one developer. Tasks should not be more than 4 hours or split up into subtasks Tasks should be linked to corresponding functions on other platforms.

MUST NOT have any requirements. Those belong into the Task Estimation and logging of hours must happen on sub-tasks

4. Bugs

Clients and testers create bug tickets. Bugs must contain:

Steps to reproduce
Screenshot (ideally from TestFairy)
Details on the device, OS, user and state

5. Client feedback

Clients and Crashlytics create issues as "Client Feedback". The project manager details and reproduces those before changing the type to "Bug".

6. Unclear bugs

If we cannot reproduce a bug, we keep it in the Backlog as an "Unclear bug" assign the epic Later in the hope that someone can reproduce the bug.

Versioning

We use versions as an additional tool to organise tickets. The rules are loose.

However: When releasing a version to testers and clients, a version must put together with all implemented tickets since the last release.

Statuses

[X. Statusname [Person in charge]: Description]

Inbox [PM]: Clients and tools dump stuff in here, project managers add details

Needs Estimation [Project Lead]: Developer adds an "Original Estimate". // Suggestion: [(developer_estimation * 1.5 )+ 15%(for Code Review)]

Needs Approval [Client or PM]: Clients approves/declines.

Approved Backlog [Project Lead]: Approved by the client, but not ready to be taken by a developer in this sprint

Ready for Development [Dev]: Sprint backlog, filled by the project manager. A developer takes the ticket from there and moves to next status.

Working On [Dev]: Developer implements, (if UI-task: adds screenshots), assigns other dev to code review

Code Review [Dev]: reviewer approves, assigns author, author merges to dev, the author moves to QA with QA-instructions

QA [PM or QA Manager]: Project managers: reviews or asks QA-Manager to review. if failed: Assigns back to the author working on if approved: moves to client review (if no client: done)

Needs client review [Client]: Client approves/declines

Done [PM] (Won't fix [PM]: Tickets, that are not solved and need no further attention) (Duplicate [PM]: Duplicates, need to be linked to the original first) Crashlytics Issues

The PM should create a bug ticket and add the issues link in the description.

The developer should close the issue on Crashlytics once he fixes a bug and the ticket moves to Prio: 'Blocker' We use this to indicate that we cannot proceed with a ticket due to something missing by someone else. i.e. an API to be finished or a design to be created.

The project manager reviews those blockers regularly to check if the constraint has been lifted.

Guidelines

Discussions on issues belong in the comments in the issue. If we discuss something is discussed in slack or a call, the project lead is responsible for summarising the decision on the ticket.

GitHub/gitlab

Background

We use Github/gitlab to host our code.

Gitlab Structure

Although gitlab is currently only under consideration we use the following structure of groups

/handbook (the handbook)

/internal (internal documents)

/open-source/{project key} (open source projects)

/apps/{client key}/{project key} (client projects)

The first project in any project group is documentation where we host all relevant documentation in the wiki for description and the repo for content where we want version control - for instance when using merge requests to inform the team of changes in data structure by assigning them as approvers.

Gitflow

We are using a custom Gitflow.

Perennial branches

master: deployed versions
develop: clean development version, for testing and beta release
stage: merged from develop for testing (not on Android)

Guidelines

Never push or merge directly into master and develop. Only reviewed pull requests are allowed to be merged.
All feature/hotfix branches must be merged into the release branch via pull requests during the sprint
Commit & push approx. all 3 hours
Create pull request for every issue before you move to "Code Review" and assign the reviewer in GitHub
On "go live": Project lead merges to master, creates a tag and adds release notes from Jira

Naming

For Jira and Toggl to auto import the code changes, we need to follow some naming conventions.

Pull request:
- github: SEL-123 {Ticket description}
- gitlab: #123 Ticket description
  - reference the ticket in the description as well, e.g. "See #123" to have an easy to use backlink to the original ticket so that the reviewers can check the ticket contents and can enable time tracking on that ticket.
  - Remove the default "Closes #123" as it will close the ticket right after merging which is NOT what we want
Branch:
- Use - for whitespaces in the branch name (just as gitlab does when it auto-creates the branch for you), don't use _
- github: feature,hotfix,bugfix/SEL-123-{ticket-description}, e.g.
  - feature/SEL-12-awesome-feature
  - hotfix/SEL-13-awesome-hotfix (fixing something in master)
  - bugfix/SEL-14-awesome-bugfix (fixing)
- gitlab: 123-{ticket-description} (best create the branch directly from the ticket via the web UI and then check it out locally)
Commit:
- github: SEL-123 {commit description}
- gitlab: #123 {commit description}

ticket-description in branch names does not have to be the same as Summary in Jira/gitlab as there can be multiple branches per ticket. You can rephrase it as long as the meaning does not get lost.

Code Review

PR/CR Guidelines

Only use GitHub comments for the initial and short discussions. More extended discussions should happen in Slack (public project channel). Report the results (+link) of that discussion in GitHub.

When we add new libraries which have not been pre-approved via the library list, please include one of the following developers as a reviewer and describe why you used that particular library (and what possible pitfalls it has) in the PR description.

Mandatory reviewers

iOS: Tal

Android: the project lead

Web: Arni

E-Mail

E-Mails are slow (having to add all those "Hi there, kind regards") and get un-readable when more than 2 people start responding in a thread.

Also, you cannot leave a thread.

E-Mails are not allowed for internal communication - except during vacation and to forward attachments like invoices.
When forwarding documents, never zip them. Always use
Learn about filters and search suffixes in Gmail.

Bitrise

Background

Bitrise is our CD/CI for Android and iOS apps.

Guidelines

master and develop must always build
master deploys to App Stores or production web server
develop deploys to clients Monday 9 am

1Password

Background

1Password is where we store all our logins.

Chrome Extension

1Password has a very handy Chrome extension, make sure to use it!

Vaults

Private is where every team member can individually store all their private logins to company accounts (Toggl, Hubspot, ...)
Company Accounts is where our team can access all our shared accounts (Udemy, developer tools, ...)
Payments is where our team can access our company cards (We limit access to that vault on a need to know basis.)

For email addresses that contain sensitive information, they are in other hidden vaults.

Chrome Extension

1Password has a very handy Chrome extension, make sure to use it!

Vaults

Private is where our team can store all their private logins to company accounts (Toggl, Hubspot, ...)
Company Accounts is where our team can access all our shared accounts (Udemy, developer tools, ...)
Payments is where our team can access our company cards

We give our employees access to vaults on a need basis for security purpose.

Core processes

Developer Operations

1. Background

We love to develop apps and websites which will be loved by users and clients.

We want to be transparent and dependable for our client. We also want to sync crowd testing and processes of our clients as well as reduce misunderstandings and unclear tickets.

At last, we want to limit crossfire from clients throughout the week and "jumping" in and out of projects.

2. Staffing

We staff every project.

With a project manager
One platform lead and one (or more) supporting frontend developer per platform
One (or more) backend developers

3. Timing and Budget

We practice Rapid Software Development. We aim to get apps to the store within 8 weeks after the briefing.

week 1: concept, wireframing and architecture
week 2: design, estimation, setup
weeks 3-6: coding (3 development cycles)
weels 7-8: testing and fixing (by crowd and client)

Overhead: We should not spend more than

15% on project management (including the project manager!)
15% on fixing bugs after releasing the first beta
15% on QA and testing
15% on refactoring

4. The Development Process

Weekly cycle

Project manager moves the weeks worth of tickets to Ready for Development before Friday noon.
Weekly staffing and update meetings on Friday between project managers and team leads
- What did we achieve/not finish last week?
- Which epics are we tackling this week?
- Roadblocks: We raise them. However, do not solve them.
- Solving staffing issues and bottlenecks
After: Team and project leads go through Ready for Development and delegate tickets to the team
Development
Developers: Implement and review all tickets from the development cycle ready for development till Thursday evening.
Project manager/QA managers: Reviews all tickets on develop branch and report bugs.
Developers: Fix those bugs.
Project leads to ensure that develop is working and testable build deployed to TestFairy
QA manager reviews the feedback from the testing agency and creates bugs tickets in Jira.
Project manager distributes the test version to the client with release notes for review

Ticket life-cycle

Tickets always need to include a billable or unbillable label to insure the accuracy of our revenue reports.

Project manager creates a ticket, adds the relevant description and moved to Needs estimation and assigned to Project lead
Project lead reviews the ticket for sufficient information and estimates 1h/ 2h/ 4h
Once estimated, the ticket is moved to Needs approval and assigned to project manager
Project manager (or client) approves, moves the ticket to Approved backlog and assigns the project lead
On Friday, planned tickets for the following sprint are moved to Ready for development.
The developer grabs an assigned ticket in order of priority and moves to Working on.
Once the ticket is complete, the developer creates a Pull Request assigned to the project lead and moves the ticket to Code Review.
Project lead approves the PR and assigns the ticket back to the developer
[GitLab Flow] The developer moves the ticket to QA when the branch is merged to develop and assigns the QA manager to test the ticket
[GitHub Flow] The developer moves the ticket to QA and assigns the QA manager to test the ticket on the separate URL (specific for this ticket).
[GitLab Flow] The QA approves the ticket and moves to Done; the original developer is assigned again
[GitHub Flow] The QA approves the ticket, merge Pull Reqest and moves to Done; the original developer is assigned again
The QA manager moves rejected tickets are moved to Ready for development.

Guidelines

The person responsible for the next step must be assigned to the ticket. i.e. when asking a question that question that blocks the ticket, please assign the person you asked.

Order of work: Weekly priority sent up until Monday; Priority: Critical, Status: Needs estimation, QA, Code Review, Working on, Ready for Development

All tickets must receive

Code review
App/web: a functional review by the Project manager or QA manager
API: a functional review by front-end developer

Pull requests

Developers create a pull request from their feature/hotfix/bugfix branch to develop branch.
Assigns the Project leads for code review on GitHub.
Project leads reviews code and approves PR (reviewer is not merging PR)
Author of pull request merges to develop and moves the ticket to QA.

Testing

The project lead developer creates a testable version on Friday EOD.

A QA manager ships a testable build to the testing agency. Each release is tested by internal testers or our test agency over the weekend.

Client feedback

The client gives feedback throughout the week (report bugs, adds request changes). For that, they are invited to do that directly in Jira.

Only tickets we get till Thursday can be part of the next development cycle.

Project managers review, reproduce and detail client requests/bug reports and creates and details Epics, breaks down to Tasks and coordinates priorities with the client on an ongoing basis.

The project lead breaks down Tasks to sub-tasks for each platform and create API sub-task tickets, estimates sub-tasks and tasks (if no subtasks) and moves them to Needs approval.

Release policy

Major/Minor Release

Monday-Wednesday. Thursday if critical.

Hotfix Release

Hotfixes on a Friday, only if 10%+ users are affected.

Major Releases

Are used sparingly — only 1-2 major releases per year.

1.0, 2.0, 3.0

Minor Releases

Every release with features in it increments the second digit of the version.

1.1, 2.3, 2.5

Hotfix Releases

Releases that merely fix bugs are incremented with the third digit of the version.

1.1.1, 2.3.4

Build numbers

We use automatically increasing build numbers from Bitrise. We use the same build version as Bitrise build.

Tickets

Ticket live cycle

Topic	Project manager	Project Lead	Developer
Ticket description	Implement	Review
Estimation		Decide
Creating subtasks		Refine	Advice
Push back on complexity	Advice	Advice
Release dates	Refine	Advice
Delegating tickets		Decide
Architecture		Enforce	Implement
Review code		Review

Project setup Android

Ask Martin to create a new repository
Check out the repository
Create a new app in the checked out repository
- In the create-app-flow select Fragment + ViewModel (package is feature..ui)
- Add Kotlin support
- Select API 21+
Add Navigation Components and convert MainActivity to use navigation to load the first Fragment
Add /.idea/navEditor.xml to gitignore
Set compile options within Android:

compileOptions {
	sourceCompatibility JavaVersion.VERSION_1_8
	targetCompatibility JavaVersion.VERSION_1_8
}

Add data binding in app's build.gradle:

dataBinding {
	enabled = true
}

Configure build types:

buildTypes {
	stage {
		matchingFallbacks ['release']
		minifyEnabled true
		proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
	}
	release {
		minifyEnabled true
		proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
	}
}

Configure bitrise
Set up Code Style.
Set up architecture (general, DI etc.)

Code Style Android

Setup

All our projects follow the Android Kotlin Code Style (with one exception: line length 140 chars) for all Kotlin classes. We use ktlint for automated checks.

To make our lives easier we use the ktlint-gradle-plugin.

In your project build.gradle:

buildscript {
  repositories {
    maven {
      url "https://plugins.gradle.org/m2/"
    }
  }
  dependencies {
    classpath "org.jlleitschuh.gradle:ktlint-gradle:<current_version>"
  }
}

apply plugin: "org.jlleitschuh.gradle.ktlint"

subprojects {
    apply plugin: "org.jlleitschuh.gradle.ktlint"
}

Then create a file called .editorconfig in the root of your project:

[*.{kt, kts}]
max_line_length = 140

Make sure to now run ./gradlew ktlintFormat and fix all issues popping up.

Don't forget to set up your IDE and bitrise as well

Android Studio and git integration

When importing an already existing and ktlint-enabled (see section above project you need to configure Android Studio to comply with the code style as well (this needs to be done on a per-project base by everyone who wants to work with ktlint enabled projects:

Just execute the following two calls to configure your IDE and git for this project and add a pre-commit hook to do the checking (and if necessary formatting for you):

./gradlew ktlintApplyToIdea
./gradlew addKtlintFormatGitPreCommitHook

Make sure to check the Run Git hooks checkbox if you commit via Android Studio (should be set by default).

Last thing to do is setting line length to 140 (Preferences -> Editor -> Code Style) - unfortunately ktlintApplyToIdea can't do that for you.

CI

Add the following step to your workflows to have bitrise check your code style as well:

	- gradle-runner@1.8.4:
	    inputs:
	    - gradle_task: ktlintCheck
	    title: ktlint

Additionally make sure that you have defined the following environment variables:

	- opts:
      is_expand: false
    GRADLE_BUILD_FILE_PATH: build.gradle
	- opts:
		  is_expand: false
		GRADLEW_PATH: "./gradlew"

Release Procedure Web Projects

1. During Development

During the week we merge feature/bugfix branches into develop.

The CDCI auto-deploys to the firebase.hosting develop environment.

Responsibilities

@devs: Codes, creates PR and merges
@project lead: Approves PR
@qa: Test features on develop.

2. Creating a testable version

Thursday evening develop is merged into stage to have a stable environment for QA, test agency and client approval.

The CDCI automatically deploys to firebase.hosting stage environment.

Responsibilities

@pm: Decides on time and date
@qa: Gives the green light
@project lead: Merges
QA: Do smoke testing
Test agency: Smoke testing
Client: Smoke testing and approval

3. Go Live

Between Monday and Wednesday, we deploy to production by merging stage into master.

CDCD auto-deploys to firebase.hosting production environment.

Responsibilities

@pm: Decides on time and date.
@qa: Give green light.
@project lead: Merges.
@qa: Do post-go-live smoke testing.

Documentation

Always keep the project documentation in confluence up to date before moving your ticket to QA.

We document EPICs in confluence and only link from Jira tickets.

Template

1. Jira Epic

Link to Jira Epic

2. User stories

List of included user stories = functional requirements (describe what’s in scope)

List of not-included user stories (describe what’s out of scope)

3. Requirements

List of non-feature requirements

4. Architecture

Description of API components, i.e. firebase, GAE, 3rd party APIs with links to documentation

5. Views

List of all views with different platforms and screen resolutions with links to Zeplin

Name	Link

6. Tracking

7. Links

Add link, that only links that pertain to this epic.

8. Todos

Non-ticket todos

API Guidelines

Permissions & Setup

IMPORTANT: Only the backend team is allowed to create firebase, contentful or GAE instances.

They do that via a script that ensures all our policies are enforce.

If individuals set up those instances, they forget imortant security or permissions policies and endangering our operations or even clients data.

Background

The decision for an API can have tremendous implications for the overall effort (and pain) of developing frontend. We have seen projects exploding 10x because of APIs we had no control over.

Preferred solution: 100% control

1. Own API

When we need a complex backend, our fearless backend team build a rock solid, high performance, super scalable, 100% unit tested and monitored thing of beauty on Google App Engine in Python.

2. Firebase

For smaller projects and prototypes that only need lightweight auth, data or file storage we use firebase.

Upsides

Do not need a backend developer to build things
The real-time database can function as a mock API (supports most HTTP methods including POST, PUT and DELETE)
Changes can be monitored in real time
Super easy integration
Real-time database

Downsides

Firebase has no build in server-side logging and makes debugging a pain
Changing data models is virtually impossible
Data can be broken super fast - esp. on production
Analytics on the data structure is hard

Third-party APIs

Should clients force us to use a 3rd party API or one they are building, we always build a proxy.

The front-end developers then draft the API as they would need it.

The proxy then translates between the frontend API and the 3rd party API.

Upsides

Frontend development gets a highly optimised API
We can monitor the 3rd party APIs for errors and report that directly to the client.
We can hit cache and prevent outages even when the client APIs breaks.

Monitoring

We use Stackdriver to monitor for outages, errors and speed of the API itself and Runscope as well as Postman to mimic user requests to do a full end-to-end test of the API every few minutes.

CDCI

Web

Confluence (TBD)
Gitlab

Web Gitlab

Gitlab CDCI Web Guidelines

Steps

0. Get the project deploy from your local terminal

Install and configure firebase CLI https://firebase.google.com/docs/cli/
Make sure to use the correct folder for deployment, i.e. /dist /public

1. Set up variables in settings/cd_ci

FIREBASE_PROJECT_DEVELOP
FIREBASE_PROJECT_PRODUCTION
FIREBASE_PROJECT_STAGE
FIREBASE_TOKEN

The central token is in 1password.

Do not protect them the variables. Otherwise, they are not be passed to the develop and stage branch.

2. Set up CDCD file in root

Add a .gitlab-ci.yml file on develop, then merge down to stage and master.

Be careful! This will deploy to production.

image: node:latest

deploy_review:
  stage: test
  environment: develop
  only:
    - develop
  script:
    - {ADD YOUR YOUR BUILD STEPS HERE}
    - npm install -g firebase-tools
    - firebase deploy --token=$FIREBASE_TOKEN --non-interactive --project=$FIREBASE_PROJECT_DEVELOP --only hosting

deploy_stage:
  stage: deploy
  environment: stage
  only:
    - stage
  script:
    - {ADD YOUR YOUR BUILD STEPS HERE}
    - npm install -g firebase-tools
    - firebase deploy --token=$FIREBASE_TOKEN --non-interactive --project=$FIREBASE_PROJECT_STAGE --only hosting

deploy_production:
  stage: deploy
  environment: production
  only:
    - master
  script:
    - {ADD YOUR YOUR BUILD STEPS HERE}
    - npm install -g firebase-tools
    - firebase deploy --token=$FIREBASE_TOKEN --non-interactive --project=FIREBASE_PROJECT_PRODUCTION --only hosting

3. Todos

Use cached folders to speed up deployment time
Gitlab wants testing (develop), and deployment handled differently. Research how that is done.
Use a centralised CDCI file to save config time.
Which firebase token should we use?
Create artefacts. Ideally, we can download a working snapshot of the build.
Review if all those steps are required or if we can skip some 7. npm install -g npm@5.6.0 8. npm install 9. npm run build

People operations

Recruiting

Guidelines

As we grow the complexity of operating the company grows. To run our company efficiently, every new team member must raise the bar. Towards that end, every recruit must be better than the median member than that team.

Preferably every recruit is better than any member of that team and especially the manager of that team.

We are acutely aware that hiring - as all people related questions - is a profoundly biased process. In addition to that, bad hires are very costly both financially and culturally.

To remedy those biases we created an elaborate process with multiple steps and at least 5 interviews.

Process

See our private recruitment section.

Note: This information is private, as they contain tasks candidates need to solve and questions they need to answer.

Being able to prepare in advance defeats the purpose.

Contracts

As we have access to clients production databases, we are subject to data protection laws, non-disclosure-agreements and data-processing-agreements with all our clients.

In those contracts, we are responsible for enforcing the same clauses to all our team members.

Every freelancer and employee needs to sign 3 documents:

Non disclosure agreement: Template
Data processing agreement: Template
Core contract 4. Freelancing contract: Template 5. Employment contract: Template

We only use digital contracts via DocuSign. Paper is a pain.

Freelance vs. Full time employee

We prefer working on a freelance basis because of this.

reduces the accounting and admin overhead by 90%
captures our entrepreneurial spirit
is closer to our processes

Some countries have "fake-freelancer-laws" that prohibits this practice sometimes. In those cases, we go with the employment contract.

Compensation

Background

We provide a transparent and unified payment scheme based on hourly rates that reflect the impact for the company, responsibilities and scarcity of the skill set.

Developers and project managers

New guys: 25€
Mid-level: 30€
Senior: 35€
Project lead: 40€
Team lead: 45€

QA manager

Junior: 15€
Mid: 20€
Senior: 25€
Team lead: 30€

We do not downgrade existing hourly rates. We will heal the existing "injustices" with a general rate increase or our team-member-profit-share program in the next years.

Full-time employees

Full-time employees get a wage based on the gross cost hourly rate + 20% (employer payment for pension health insurance, ...) x 8 h / day x 220 d / year.

So if an employee and a freelancer work that 1760 h per year, they cost the company the same amount.

220 d is the average per full-time employee in Germany.

1700 h was the average of full-time freelancer at stanwood last year.

Example

Employee:

Wage: 40 €/h x 8 h/d x 220 d/y x 80% = 56,320 €

Benefits: 40 €/h x 8 h/d x 220 d/y x 20% = 14,080 €

Freelancer

Fee: 40 €/h x 8 h/d x 220 d/y = 70,400 €

Perks

Headspace Subscription

One of our goals is to reduce stress level and help ourselves with mental health issues.

For us a mental health issue is just a health issue as a broken arm or a cold - although tougher to heal from.

Towards that end do we offer every team member and alumni a free subscription to the meditation & mindfulness app Headspace.

https://work.headspace.com/fooxessoftwareentwicklungsgmbh/join

Hot desk in the coworking of your choice

Being remote, we obviously don't have an office anymore. While a major part of our team works from home, we know that some people prefer working in a coworking.

Onboarding

New team members (aka Wookies) need these accounts.

All accounts (except GitHub and Gitlab) must be the @stanwood.io email.

0. TODO Wookie / new employee

Ask them to read this handbook thoroughly!

1. E-mail

https://admin.google.com/stanwood.de/AdminHome

Create an e-mail firstname.lastname@stanwood.io

Lead sends a password to private email or mobile phone of the user and asks new employee to change PW right after logging in.

All following invites (if not mentioned otherwise) go to that new Email address.

2. Slack

https://stanwood.slack.com/admin

Add user
Add user to group

The new handle will only be usable after registration.

ToDo Wookie Choose username by following Guideline guideline

3. Github and Gitlab

Add private GitHub.com and gitlab.com handle to teams if handle already exists.

https://github.com/orgs/stanwood/teams https://gitlab.com/groups/stanwood/-/group_members

ToDo Wookie

If you have no account there, create new account and send your username to your lead
enable 2FA

4. Toggl

https://www.toggl.com/app/team/1229046

Add user
Add user to a group (used in accounting)

5. Jira

https://stanwood.atlassian.net/admin/users/add

Username: Only the first name

Add to the group: "Developers."

User will be added to the Holidays calender and All hands meetings

9. Applause

https://platform.applause.com/account/usermgmt/teammgmt

10. Add birthday and anniversary to Hannes Calendar and Spreadsheet

https://docs.google.com/spreadsheets/d/1Te6wxnS8Bu_WSHf4Eio567Uk4_kmA8hduZL9HUK6ksc/edit#gid=0

11. MyTaxi

https://de.mytaxi.com/login.html?target=corporate

12. Trello

https://trello.com/stanwood3/members

13. appear.in

https://stanwood.appear.in/org/users

14. Zoho

Teamlead adds Wookie to zoho people.

ToDo Wookie Update your info in https://people.zoho.com/stanwood/zp#selfservice/user/profile

Zoho Expense (Employees only) Employees expense with zoho expense. https://expense.zoho.com/app#/usersmanagement/users

15. Bitrise

ToDo Wookie If you have no account there, create new account and send your username to your lead

16. TODO for Wookie: Setup Jira/gitlab + Toggle Sync:

Install and configure our own Toggl Chrome extension fork: https://gitlab.com/stanwood/internal/tools/toggl-sync/wikis/home

New devs: Enable Toggl + Jira Sync, please: https://toggl-jira-sync.appspot.com/login (still needed with the aforementioned?)

17. For PMs only: Hubspot

https://app.hubspot.com/settings/4628060/users Use 2FA!

18. Add them to our Shared GDrives

Shared Drives

19. After they accepted everything:

Add them to the project and general slack channels. Welcome them in #general

Continuous Performance Management

1 on 1 reviews

We do continuous performance management. Leads have regular 1 on 1 reviews with their team members.

We centre on these questions:

What are you working on?
How are you doing?
How are your OKRs/Goals coming along?
Is there anything impeding your work?
What do you need from me to be (more) successful?
How do you need to grow to achieve your career goals?

This is the team members meeting. Tone and agenda should be set by the team member. The lead is there to coach and learn.

Background information: https://gitlab.com/stanwood/blog/blob/master/inspirations_from_books.md#L208-214

People development

Background

stanwood is the embodiment of change. We want to improve every day. One crucial step (others are Analyses, Planning, Doing and Collecting Data) is the Review.

1. Personal development review

Every team member has a personal development review meeting with their team lead four times per year, where we review 360° feedback.

Apart from general feedback, your lead discusses these points:

Developer ideals
Team KPIs and how you might contribute
360° feedback

With the Q1 feedback in 2019, we add personal goals and personal KPIs.

1. Goals

Numerous studies have shown, that setting goals increase a teams performance and personal happiness.

We already have our company goals for each year.

We start developing (bottom-up) goals for every team in 2018 and every person in 2019.

Those goals can - but must not overlap - with the higher team and company goals.

Goal achievement is purely developmental and is not tied to your compensation or career.

2. KPI

We are blessed with numerous sources of data that can help us understand our performance as a group.

When setting goals, we try to use data to inform our decision making.

We also use data to identify patterns and improve our operations.

We never use data to control or punish people.

KPIs are purely developmental and are tied to your compensation or career.

Developer KPI

Estimation accuracy
Feature implementation speed
Bug fixing speed
% worked on bugs vs features
% tickets passing QA on the first try

QA KPI

% tickets passing QA on the first
Total number of tickets reviewed
Number of bugs found by the client

Project management KPI

Estimation accuracy
% worked on bugs vs features
% tickets passing QA on the first try
Project profitability

3. 360° Feedback

We want to give you a fuller picture of how you are perceived by our fellow Woodies and even clients (for project managers).

For that end, we identified up to 7 people each Woody worked with most - that gives anonymised feedback and vice versa.

This survey is purely developmental. Nothing you say here impacts compensation or the career of that person or yours.

I. HOW TO

Please choose your feedback partners from this list Pairings

moreover, leave them short and actionable feedback here

Form

II. EXAMPLES

Keep "Fun to work with, a good mentor, always available to help when I have technical issues, or I am blocked with a task."

Change "Share more from his/her experience in programming channels so I can learn, delegate more interesting tasks where I can improve my skills, "

III. NOTES

This survey is anonymous towards the person you give feedback.
Hannes sees all answers and your name.
Team leads see all answers for their team and your name.
The team lead synthesises all feedback to ensure anonymity.
If you do not have 7 people on your list, click "NEXT" and leave those sections empty.

4. Leadership feedback

Our team leads get a bit more detailed feedback. Every team member answers the following 12 questions.

My team lead gives me actionable feedback that helps me improve my performance.
My team lead does not "micromanage".
My team lead shows consideration for me as a person.
My team lead values the perspective I bring to the team, even if it is different from his own.
My team lead keeps the team focused on our priority results/deliverables.
My team lead regularly shares relevant information from his bosses.
My team lead has had a meaningful discussion with me about career development in the past six months.
My team lead communicates clear goals for our team.
My team lead has the technical expertise required to effectively manage me.
I am satisfied with My team lead’s overall performance as a manager.
What should My team lead keep doing?
What should My team lead change?

This is based on Google's research what kind of leader makes teams most effective.

https://qz.com/1058760/manager-feedback-at-google-employees-are-asked-13-questions-about-their-bosses-as-part-of-a-semi-annual-review-goog-googl/

Performance Management

We will be introducing a separate performance review process in 2019 because of the following occurrences from 2018/2019.

Team members quit because or rated our compensation and promotion policy as unjust across teams.
Team members were surprised when we let them go because they were not aware that their performance in the company did not match our expectations.

When stanwood was just ten people the managing director could talk to everyone in the company enabling

Fair and calibrating compensation and promotion
Explain every decision
We also did not let people too because we valued relationships more than performance and impact on the team or clients.

stanwoodgeist survey

We want to create the best place to work. In a growing company it get's harder to get everyones feedback and synthesise that up the chain of command. Some feedback we never get despite our best efforts. Either because it's too personal, the team member does not fully trust their manager or just because they are too shy in general.

To get a comprehensive picture on how we see the company on various aspects and identify areas of focus on, we sent out the stanwoodgeist survey every 6 months covering topics around

Work
Culture
Leadership
Fairness

TODO: @hanneskl: Add questions here

Training

Background

We want to get better at what we do every day. For that we offer the following tools:

Courses

We pay both hours and courses for everyone to learn any (really any) of the trades that we use at stanwood. If you are a coder, who wants to learn to design: You are welcome — a QA manager who wants to learn Accounting: Yes, please.

Just ping the MD or your team lead, and we set you up.

Masterclasses

Every Wednesday at 10 am CET we hold a masterclass where one of our own gives a 30 minute talk (strictly enforced) about an exciting topic.

All masterclasses are voluntary.

We use record those classes for later consumption.

Check #masterclass for more info.

Meet-ups

Retreats

We meet 2x per year for a two-day workshop.

Workshops

Between the retreats, teams can meet as often as they see fit.

Grill the boss

Every week the managing director invites one Woodie to fly to Munich and spent an evening cooking and drinking. Every new team member is invited in their first two weeks.

Woodie can ask all the deep questions and meander with the Supreme Mugwump about vision, strategy and all things geek.

All expenses paid of course.

Meet a Woody

If a Woodie wants to meet another Woodie in person, we are sponsoring the flight with up to 200€ and a stay at the hotel up to 100€.

Send a direct message to the MD and explain why you want to go.

We will be generous.

The visit can be be project related or just because a Woodie always wanted to meet the other person.

Groups are also allowed, for instance, to do a team kick off or celebratory launch party.

Travel and Expensing

Background

We try to minimise the accounting overhead of traveling as much as possible.

Every Woodie get's a company virtual credit card via pleo.com and is responsible to adding the recipts to Pleo.

Sales, consultants and leads get real credit cards to pay in restaurants.

Booking process

All travels are organised in Trello.

When we need a travel, we create a card in "Planing".
Add a location, attendees, dates and required actions in a checklist and assign who is responsible for it.
As soon as everything is booked, our office manager moves the card to "Booked"
After the event, the main attendee writes a quick summary (optional) and moves to "Done".

Then add your flight times to the holiday calendar with "{my name} {flight number}", in order for the organisers see your flight times.

Hotels

Our office manager books hotels in #office centrally for everyone. Invoices are paid by the company via credit card.

Flights

Every team member books and pays their flights, train rides or car trips themselves with their company credit card and expenses them.

Dinners

When two Woodies meet or meet with a client, the company pays for food.

What we pay for

As a general rule: You are a guardian of the company. We trust you to make the right choices and spent our money wisely.

Flights

Economy class on first tier airlines (Lufthansa, BA, El-Al)
We try to do direct flights only - outside business hours to minimise cost, stress and lost work time
Feel free to upgrade your seats to emergency exit row, if you are want to to work
Frequent travellers (30+ flights per year) may book business class

Trains

Business or first class if you want to work
Economy class if you want to chill

Hotels

Motel One
London: Pullmann

Conference Rooms

Wework, Business Link or Mindshare

Food & Drinks

We do dinners burger-and-beer-style. Anything fancy needs prior approval by the MD.

Food during events

We have breakfast at the hotel
Lunch is paid by the company
Dinner is paid by the company
Drinks are paid by the MD (if present) (Note: This is not tax-deductable.)

Time Tracking

Background

We (mostly) invoice our clients based on hours worked.

We get paid by the hour. Our clients honor us with a tremendous amount of trust - in return we give them total transparency.

Update 2019: We are reworking this part. We want to get rid of time tracking as much as possible to reduce our stress level.

They expect splits by ticket or overhead tasks.

Working hours

When you work is up to you, but make it transparent to the project team, and the team leads. But you must make sure to be able to react during CET hours.

Make sure to answer all messages in slack at least within 1h during 10:00 and 18:00 CET. This is only required if you have not marked the day or period in the Holiday calendar. See the chapter on Slack for details.

Public holidays and vacations

Use the GCal Holiday calendar to put in your vacations. A 4-week head start would be good, so the leads can plan the projects.

Check with the PM that we have no releases or major events planned during that time.

Also make sure, that the developer from your platform / other PM is not on vacation as well.

Post in #status, should you be away from the keyboard for more than 1 h during 10:00 and 18:00 CET

Workshops

When participating in or preparing for a workshop book on "Internal Workshops".

Travel

We do not pay for the time you spent travelling, so please do not book it.

However, if you bring your laptop and work while on transit, please usually book on the project, and you will, of course, be paid.

Masterclasses

Please book the time for participating and preparing for Masterclasses on "Internal Workshops".

Marketing / Content

Marketing, writing articles and posts or work on our own website are tracked on "content"

Onboarding

If you are a wookie in your first onboarding-weeks, you can book onboarding time on "onboarding".

Sales

When you are helping with a pitch or a sales presentation, please book on project "Sales".

Naming

Use the Jira ticket ID and description, i.e. LEN-01 My awesome new feature Assign a project.

Best do it realtime. Use Toggl-Jira chrome extension

Book non-ticket project work on one of the Tasks in Toggl:

Client communication
Internal communication
Estimation
Ticket review
Test agency
QA
Testing
Deploying

On invoices they get mapped to

Added pro rata to tickets
- Internal communication
- QA
- Testing
Consulting
- Client communication
Concepting
- Estimation
Project management
- Ticket review
Review test agency
- Test agency
Deployment
- Deploying
- Service Desk

Book non-project work on project Travel & Admin. Always book project work on projects.

Off-boarding

We strive to be a company that does not have to fire people.

However, even the best hiring and people development process fails from time to time, and we have to part ways with a person.

We give feedback at least every 6 months during our performance reviews.

There are 5 main reasons for ending or not extending a contract:

Gross negligence or malicious behaviour hurting a client or the company
Hurting another Woody or poisoning the team athmosphere
Not following our vision and values
Long term under-performance with no improvement through coaching.
Financial strains the company cannot overcome
The employee asks us to end the contract

Process

This process is only valid for reasons #3.

#1 leads to immediate termination without any severance package

For reasons #2, #4 or #5 we only honour the contracts.

The team lead and the MD decide to start the process.
All team leads discuss the issue.
Team leads have a veto that the MD can override.
The Woodie is told by his lead with Hannes present, that he/she is officially on-notice for four weeks and what changes are required to stay in the company.
Daily check-ins with Hannes and the respective lead.
After 4 weeks the leads and Hannes review the process and decide to either
- End the contract
- Extend the contract
- Extend the on-notice period by another 4 weeks
The employee is told the decision by the Lead with Hannes present
Hannes will inform the company about the decision and the reasons
Should the contract be ended, we offer a 4 week grace period during which the employee gets full pay
The developer must show 200% commitment during those 4 weeks including reporting every ticket when they start and end working on to the team lead and project manager
stanwood uses all their contacts to find another engagement for the developer

Last day

Ops

Disable all accounts from on-boarding

MD

Write a personal note to the person leaving
Thank the person on #general

Person leaving

Reply to MD post with a personal message to the team and leave your private email to stay in touch [Optional]
Remove stanwood GDrive
Remove all accounts and passwords from password manager
Remove all code repository and stanwood docs from your computer
Remove all private data from your computer [if company computer]
Reset all devices to factory settings [If company hardware]
Sent hardware back to MD [if company hardware]
Sent last invoice (if freelancer)

Alumni

Every team member who leaves the company on his accord will become part of the esteemed club of stanwood alumni.

Stanwood Alumni Perks

As a Stanwood Alumni, you:

Keep your email and slack account
Get invited to all company retreats and workshops (travel expenses are paid but not the hours).
Can keep using your Private 1Password Vault

Support processes

Accounting

Tools & Processes

All ingoing an outgoing invoices are digitised and then sent to invoice@stanwood.de (alias of info@stanwood.de).

That forwards it to candis.io for processing.

Payments are made every Monday morning from candis.io and the local tool MoneyMoney by the MD.

On the next Monday that is not the 1st of the month is closed.

The MD adds cost centres and accounts numbers to all invoices.

Our accountants (Goldstein Consulting) get an export of all data, do some accounting magic and create cost centre reports for all teams.

Cost centres

Every lead is responsible for a cost centre.

1000 General Management @hannes
- ~~1100 Sales & Marketing~~
  - 1110 Sales @richard
- ~~1200 Finance~~
~~2000 Product & Project Management~~
- 2100 Project Management @richard
- 2200 Quality Assurance @richard
~~3000 Software Development~~
- ~~3100 Mobile Development~~
  - 3110 iOS Development @tal
  - 3120 android Development @milosz
- ~~3200 Web Development~~
  - 3300 Backend Development @marcin
  - 3400 Web Frontend Development @arni
~~4000 Operations~~
- 4100 Hosting @marcin
- 4200 Tools @hannes
~~5000 Squads~~~
- 5100 Squad 1 @marcin
- 5200 Squad 2 @tal
- 5300 Squad 3 @richard

Freelancer Invoices

Invoice needs to be in German or English. Can have your language as well.

Required elements

Full name of the company or freelancer
Full address of the company or freelancer
Full address of stanwood (take from website imprint)
Tax ID or VAT ID even if there is no tax applicable
Date of the invoice
The month of service provided (usually the prior month
Invoice number: Incremental
Hours worked and hourly rate
Description i.e. "Software development", "consulting"
Add extra lines for travel expenses
Net sum
VAT tax rate and sum (usually 0% and 0€ because of reverse charge)
Gross sum (net + tax)
If reverse charge
- add "No tax due to reverse-charge."
- add "stanwood VAT ID: DE 321356612".
IBAN and BIC

In Germany, you might be a "Kleinunternehmer". Check with your accountant and then add this to your invoice:

 "Als Kleinunternehmer im Sinne von § 19 Abs. 1 UStG wird keine Umsatzsteuer berechnet."

Process

On the first of the month
Grab your hours from Toggl
Create an invoice with those hours
Sent it to your Squad Lead for approval. (Do not put the MD or invoice@stanwood.de on CC.
Your Sqaud Lead will review your invoice and forward it himself.
On the 15th you should have the money on your account.

Processing invoices

We are using a central email 'invoice@stanwood.de' to get all invoices into our systems and incorporates'.

Those emails get forwarded to a candis.io account (to have a central log for all emails) and then forwarded to corporates invoice address.

Corporate processes all those emails and assigns them to our office assistants. They assign a cost centre and approve it.

After 1-2 days, those invoices are assigned to our MD who approves as well.

After that, another corporate employee approves the invoice as well. With that, the invoices are paid 1-5 days later.

The whole process takes 10 business days at best and sometimes up to three weeks.

Sales and Marketing

Our skills

Digital Transformation

App data
Consulting: Big data scientiesty + business casper
Business planing and concepting
Street credibility
ON AIR
Corporate background
Funke Exit

Product management

Lean development: Scope Management
Designen, Coden, Deployment, Hosting, Maintaining, Marketing, Monetization

Distributed

Best and happiest coders
Around the clock
Mindset
Modern
One person in every country #glocal
"Cultured code"
Fits to distributed clients
Digital nomad family
Transparency

Passions

Fun with nerds
Techies
Number chruncher
Food & Booze
Work 2.0
First 100% distributed agency
Distributed
Lean product development
Digital transformation
Build stuff

Tilt

Overlap of our 3 core skills.
Define "Stanwood Persona" after client personas

Segments

"Interims CTO" Inkubator
"Workbench" for agencies
"Industry 4.0"

SME
Agencies

Content

1. Distributed

Meta: Work 4.0, Benefits, Lean
https://gitlab.com/stanwood/handbook/
Add new processes
Focus on core processes
Culture
Health
Home stories & portraits
Origin story
Sales Strategy
Workation
Future of stanwood (3 / 5 remote)
Hannes/Richard/Martin private digital dungeon

2. Product management

MVP - Why
Global development process - How to get an app to the App store in 2 months
Data driven product development
Feature creep
A/B
big data
machine learning
Agile software development
QA (add applause)
Monetisation strategies
News apps
(Jean)
App Store Optimization
Product stories
All our products & interviews
Hosting & API
No admins
No server
Highly scalable
Monitoring
Google AI APIs
Client communication
Bots
Lesson learned
Analytics
Onboarding
useronboard.com
IAP & Paywalls
Best practises
Why Apple will reject you
Apple approval strategy
1.0 in Luxembourg
Server side feature flags
Design processes (re Wunderdeals)
Retention and conversion optimisation (CRM)
Push notifications & deep links
CRM
Cross platform coding (Flutter, Phone Gap, Xamarin, react)
Sync iOS and android development
Multi project management (defrag)
How get 5 star ratings
App development costs
Multi-tenant apps
Next tech: Bots, AI...

3. Digital Transformation

Product stories
Change management
Internal
Clients
Tools: Introduction
Content Marketing
How to make your company future proof?
No back-office (candies, Zohoo, Goldstein, weworks/mindspace)
Paperless

Marketing Operations

1. Social Media

We schedule post to instagram, facebook, twitter (MD and company accounts), linkedin (MD and company accounts) and xing (via API) via Hubspot's social media publishing tool at least 7 days in advance.

We write and plan the posts in a GDoc.

Goal

Publish one post on every channel every day.

2. Blog

We plan our blog articles in a GSheet

Legal & Contracts

Note: We offer our clients "maintenance contracts" as of Apr 2019 to "keep the app running and fix all upcoming bugs" in the extent of the usual bug fixing (20% of the total budget).

Example of maintenance contract: GDoc. Maintenance contracts are drafted by MD.

Process

PMs or MD prepare quotes for the clients (in Debitoor) and attach ToU as PDF to the quote
In case PM creates the quote, it should always be approved by MD
In case PM creates the quote and it requires a maintenance contract, PM should contact MD.

Note: maintenance contracts are only sent with the initial quotes for MVPs and bigger project tasks. You don't need to attach the maintenance contract to later quotes with smaller changes after the MVP was submitted (e.g. for change requests & redesigns).

stanwood/handbook

Introduction

Table of contents

Background

Update the handbook

Strategy

Mission

Professional conduct

I. Enthusiasm & fun personality

II. Time-to-market focus

III. App quality

IV. Strong architecture and clean code

Values

I. Transparency and openness

Exceptions

Openness and honesty

Failure

Language

II. Hacker mindset

III. Constant change

IV. Ownership

III. Love it, leave it or change it

IV. Respect, Friendship and Support

V. Working remotely

Goals

Company OKRs 2020

Objective 1: Sustainable growth

Objective 2: Delight clients

Objective: 3. Become the authority on digital business and remote work

Objective 4: Calm our operations

Squad OKRs

Objective 1: Profitability

Objective 2: Reliability & Quality

Objective 3: Become one team with the client

Platform OKRs

Objective 1: Build an eight A-level dev rooster

Objective 2: Reliability & Quality

Objective 3: Profitability

Responsibilities

General

Permission Management

Background

Principles

Roles

Leadership

Background on leadership

Leadership criteria

Technical skills to become a leader

Train your successor

Team lead

Philosophy

Lead by example

Responsibilities

Improve the company

Recruiting

Staffing

Technology

People development

Training

Personal support

Project lead

Responsibilities

Application Architecture

Project planning

Project execution

Application Documentation

Code review

Senior developer

Responsibilities

Design and implement new features

Maintain and manage the existing code base

Project managers

1. Client Communication

Keep the client close

Measure client satisfaction and improve

2. Jira/gitlab Hygiene

3. Internal communication

4. Sprint steering

5. Make sure we hit 50% project profitability

6. Keep documentation and Zeplin up to date