

## 🕖 1. Focus - Plan your day

- Identify three things you want to achieve for the day
- Timebox - Set out time in your calendar to focus on each of them. It will encourage you to set aside time to devote to each of your three priorities
- Plan ‘free / thinking time’ - Don’t over commit yourself in back to back meetings
- Plan a stress/worry window

## 📝 2. Your system in 4D

When tasks pile up, it's easy to feel overwhelmed. Use the 4 Ds to assist you figure out how to deal with it. 

- Do now - Something that needs to be acted on
- Delegate - Can you delegate this task to someone else?
- Defer - Can this be deferred to another time? Do you need to be doing it now?
- Delete - Does this need to be done - Can you delete/drop it?

Check it out here: 

[The 4Ds of Time Management and How To Use Them - Toggl Blog](https://toggl.com/blog/4-ds)

## 🧠 3. Get in the zone

Focus. Focus. Focus.

- During your time boxes, zone in and shut everything else out
    
    *No email, no Slack, no context switching during this timebox*
    
- Try to take blocks of 15-20 mins of pure focus - set a timer!
- You could try out the [Pomodoro](https://www.themuse.com/advice/take-it-from-someone-who-hates-productivity-hacksthe-pomodoro-technique-actually-works) technique - [Useful timer](https://cuckoo.team)

## 🪟 4. Worry window

Time spent worrying or stressing can be emotionally and physical exhausting and impact other things that you are trying to progress on. To help stop these thoughts from consuming and distracting you, acknowledge what you are thinking/feeling and address it during worry time.

- Time dedicated to your worries or stress
- If you don’t need to deal with worry or stress, take the time to rest and recharge
- Identify if you are in control:
    - If something is not in your control - defer, delegate or escalate
    - If something is in your control - prioritise when you want to address it and add it to your review at the end of the day
    - Bonus content - Check out the [worry tree](https://www.getselfhelp.co.uk/docs/worrytree.pdf) for help identifying your worries
  

    
    > *“I’m really glad I spent all day worrying and stressing about that issue”                                                 ~ Said no-one ever!*
    > 

## 🏃 5. Get yourself ahead

- Reflect on your day - Can you identify any improvements or something that you should keep doing?
- Identify your top three priorities for the next day

Time management in 5

Here at Learnerbly we believe in the power of experiments in helping our teams solve problems more efficiently. Some will fail (fast) and others will succeed in helping drive measurable improvements. More about experiments another time. 

An experiment we are running at the moment, in our Platform Team, is asynchronous **Story Kick-offs**. To understand what problem this experiment is trying to solve it serves to first understand what a Story Kick-off is, and what we intend it to achieve. 

For us, a Story Kick-off is where an engineer, or a pair, who are about to start working on a user story, discuss the story together. This preferably happens with other roles from the team, such as the designer, the product manager (PM), and/or, if applicable, a quality engineer (QE/QA).

## The **goal** of a Story Kick-off is to:

* ✔️ confirm the requirements and approach
* ✔️ create clarity and alignment within the team
* ✔️ call out any potential risks and/or uncertainties
* ✔️ share knowledge and ideas
* ✔️ potentially split the story into smaller slices of incremental value


The motivation for us having Story Kick-offs is that we believe changes are less expensive to implement further upstream, and they become more expensive as you move downstream. When questions about an approach and/or acceptance criteria are only asked at the review stage or during QA, the developer and wider team may have to pay for lost time and effort. This ultimately affects delivery.

There is also the risk of making assumptions and/or failing to mitigate risks. When we catch something early, we shorten the feedback loop, reduce waste and inefficiency, and help minimize impediments the team may face later.

Story Kick-offs are usually **synchronous.** As we are a [remote first company](https://www.notion.so/We-re-remote-726cf235e7f440c98153bf26459d91d1), for us that means video calls. We have found that it can be difficult to facilitate these just in time when the team members live in different time-zones and have vastly different schedules. **Asynchronous** kickoffs can be done using whatever communication best suits your team. For us that's over threads, in slack, or in the jira ticket comment section. Usually they will be initiated and led by the engineer (or pair of engineers) intending on starting the work. 

## During the Story Kick-off you'll want to confirm:

* ✔️ acceptance criteria with the product manager
* ✔️ mockups with design
* ✔️ technical requirements with other engineers
* ✔️ test plans with other engineers

In closing, Story Kick-offs can be a really useful cross-functional activity that can help towards team alignment, avoid misunderstandings and encourage small incremental stories that continuously add value. With any process, it's important for teams to first ask "will this provide value", if the answer is yes then it's equally as important that the process can be (and is) adapted to the teams needs.

Story Kick-offs: An experiment with time


*This is a living document and very much work in progress.*

## 🤷🏻‍♂️ We put people over processes

Every team member and project is unique. We are not bound to certain frameworks or rituals. Our processes are fluid and malleable based on what is effective for the individual and the group and constantly iterate on.

## 🕹 We are remote-first

Some of us might be located in close proximity but we approach everything we do with a remote-first mindset. We favour async communication and optimise for transparency, clarity and availability of information.

## 🤼‍♂️ We operate in small, autonomous teams

We strive for small teams that can work independently from each other. Sometimes there is an overlap but we try to keep dependencies low.

## 🧱 We think from first principles

We start with the underlying fundamentals when making decisions and think through with rigor and logic to make the best decision with the available knowledge.

## 👩‍✈️ We take risks

Things will break, ideas will fail. We do not blame anyone for trying something. Rather ask for forgiveness and share learnings than wait for permission.

## 👋 We are open to everyone

Great ideas come from everywhere. We listen carefully, no matter what background or experience someone has. Be humble.

## 💪🏻 We have strong opinions, weakly held

We have to make many decisions under uncertainty. We believe that those are the right decisions until proven wrong. And if so we move on quickly.

## 🧑🏽‍🏫 We help each other grow

We are voracious learners and teachers. We spend time sharing knowledge and helping each other. Even if it slows us down temporarily.

## ⛹🏻‍♀️ We build the product together

Teams build great products: we have our roles to play and we are all responsible for solving problems for our customers and users. Not-my-job attitudes are not welcomed here.

## 🏁 We stop starting, start finishing

We have limits on tasks in progress. We focus our efforts on the work items closest to completion before starting something new.


How we work with each other


## ☕️ We are (mostly) TS-centric

We ❤️ the JavaScript/TypeScript ecosystem and try to use it whenever we can but are not averse to changing tools when we feel it's necessary.

## 💸 Managed solutions are our jam

We want to spend our time-solving problems for our customers, not maintaining our infrastructure. We try to use managed ("serverless") services wherever possible.

## 💨 We iterate quickly and deploy often

We try to deploy features little by little and release them slowly via feature toggles.

## 🤖 We automate all that is boring

We want to focus on shipping new things, not maintaining our setup. We always try to lower the cognitive load by abstracting and automating.

## 💇🏻‍♂️ We use linting over style guides

We don't like to argue over coding style. If we want to standardise something we add a lint rule.

## 🛣 All infrastructure as code

We try to avoid the DevOps bottleneck. Everyone is allowed to provision infrastructure via shared code.

## ☁️ We are single cloud

AWS for the win.

## ⛔️ We do not have code ownership

We all share ownership of our code, people are free to make decisions, others are also free to question these.

## 💿 The tech bits

Our main API is a GraphQL endpoint running on AWS Lambda. Other technologies in use are DynamoDB, S3, ElasticSearch, MySQL. On the client-side, we use React and Apollo to build web-based components.


How we build things


It’s been 4 years since we started building Learnerbly. As a business, we talk a lot about how our product helps to [build a learning culture](https://www.learnerbly.com/articles). But what you might be interested in is how we build the product and what it’s like to work here.

It’s time to take a peek behind the Learnerbly curtain. Let’s go!


Thoughts on technology, from the people building Learnerbly

Time management in 5

Story Kick-offs: An experiment with time

How we work with each other

How we build things

Hello World