The hq repo is the home of all of dwyl's operations and administration.
If you'd like to know more about dwyl's purpose and aims or to join the dwyl community, please take a look at https://github.com/dwyl/start-here
Over the last few months, many opportunities have presented themselves and also a number of projects have been extended for additional sprints and functionality. As a result, it has sometimes been too easy to get caught up in the day to day or forget to say no, making it hard to focus on the important things rather than on what's right in front of us or is 'urgent'.
Our One Metric that Matters should be the thing that refocuses our efforts and reflects what is important to dwyl and dwylers at this moment in time.
That doesn’t mean there’s only one metric you care about [for the life of the company]. It does, however, mean that at any given time, there’s one metric you should care about above all else.
The most important thing to realise is that OMTM doesn't tie us into that metric forever more. As dwyl and our shared objectives evolve, we encourage a periodic review of these.
There are (and should be) OMTMs for each branch of the organisation and for individuals as well. There will be more detailed objectives, but it's crucial to have an OMTM so that there is a clear focus and clarity of expectations.
We learn how to do something to solve a particular problem on projects every day and that's great, but if the knowledge goes no further than an individual, how useful is it and how quickly will you forget it?
We work together. We build each other up.
The people who share what they know (i.e. record their findings in issues, write/contribute to docs, blog posts, records screen casts and write books) are the ones who stand out. Sharing immediately demonstrates to your peers (and both current & future employers/team mates) that you are a "Lead Developer"
- your experience and desire to help your team becomes self-evident.
Remember that:
- There's a high degree of certainty you will forget the details of how you "solved" something between writing the code and returning to it weeks later. Working your way through your code will waste your own time re-grokking it
- 'Others' is not just people within your physical reach. We aim to be a remote-first organisation (meaning you can work from anywhere) and we already have a remote community of over 350+ people actively contributing to your knowledge
- Your own learning is solidified by teaching
- When someone takes an hour of their time to write up something that took them a day or a week to figure out and learn, you can now learn it in 30 minutes. Think about how much time you have saved! Pay it forward.
Contribute in the form of dwyl/learn-x enhancements and implementations of these learnings on dwyl modules/products.
Don't take our word for it, here's Mattias Petter Johansson from Spotify: https://youtu.be/RleN-6uMF04
If we are not writing re-useable code we are building everything "from scratch" each time.
This is worse for the client/customer/user because it takes longer to build (and is
therefore more expensive) and longer to start getting actionable feedback from user testing.
It's worse for all future projects and team mates because it wastes future time
of people and projects who have to constantly rewrite similar things.
It damages our chances of working with clients who are doing awesome things that have
a real social impact because these are also often the clients with the least budget.
Track this and document at the end of each project.
or, if we can't get access to this data:
Both of these metrics will feed into the relevant case study for the project/client.
We then also want to integrate that feedback into our processes to make what we do better both for current and future clients.
In the short term, through surveys that are sent to POs at the end of a project.
We need to work with our clients to develop a way to help them measure end user satisfaction.
OMTM: Number of people who have used the products to save time in their lives and feel more fulfilled.
Our goal as an organisation is to "Empower people to sustainably unlock their potential and pursue their passion."
Our products will be a conduit for this goal so we want to ensure they are making strides towards it.
OMTM: Ensuring all operating (financial and human) information is available in near realtime through automatisation of systems.
I see the key task towards this as automating as many systems as possible so the data is available and minimises repetitive manual input wherever possible. HOWEVER, we also need to do this in such a way that minimises tooling and keeps to our 'single source of truth' principle to ensure frictionless updating. This is being initiated with dwyl/process-handbook#35
"Operations" is not directly responsible for bringing in revenue or creating the product, but is critical to saving everyone time and ensuring that all of the necessary information is readily available so that informed/good decisions can be made e.g. #321.
The key for us is to document all the tasks in our organisation, in particular those that are more repetitive and find ways to automate them.
There are many things that dwylers have the potential to be working on and the more of the 'day to day' tasks that don't require deep work (or thought) that can be automated, the more time we free up to live up to our potential and help others do the same.
DWYL LTD is incorporated and registered in England and Wales with company number 09525434
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent