top of page
Search

Lessons when starting from Scratch

It's very seldom you have to completely start from scratch, and there's nothing as exciting but also daunting about that blank sheet of paper in front of you.


We're currently kicking off both a new services company while also running our first idea lab. While there's plenty of lessons learned in starting a company we could talk about, I just wanted to capture some of the great take-aways from these first couple weeks of the lab.

 

Lesson 1: Setting up AWS organisations

Oftentimes working in tech you don't walk into an absolutely empty environment. There's already an organisational structure, people who have implemented or tried different things.

This is our very first lab, and so ours is a completely brand-new AWS environment. Our labs have volunteers which will come and go, perhaps daily. We can't create a new "Kind" account for everyone inside Kind. We need to strike the balance of security, convenience and cost.


In our first attempt, we learned that inviting people outside your AWS organisation to your organisation brings those people's AWS account balances with them(!!!!)


We want to provide real-world learning experiences, but not foot everyone's personal AWS bill. This was certainly unexpected, not obvious, and a lesson learned! Many thanks to Bradley Young for identifying the issue and helping out!


 

Lesson 2: Git!?!? Who, Me?!?


Whether our volunteers spend an hour or a month either mentoring or learning in our labs to get the most out of it and make the biggest impact they can.



We want everyone, whether they spend an hour or a month either mentoring or learning in our labs to get the most out of it and make the biggest impact they can.

We can start to build a bit of a skills assessment pretty quickly after the first session of working together. One of the first things which become evident is people's awareness of version control.


People working through Udemy or other courses typically jump straight to lessons about the subject area they're interested in. When they make the leap to working in a more outcome-driven way, we can identify skills which are otherwise taken as given, such as knowledge on working with git version control, or how to split up work and collaborate in an agile manner.


It'll be fun to see how this evolves. We may be able to gather an informed opinion on what everyone's favourite learning resources are, and offer effective personalised learning plans. It's also a great exercise for us to learn how to adapt so everyone can still be the most productive in delivering our goals.



 

Lesson 3. Effective Access to Information


A great marker of a well-organised system is when the biggest impact can be safely made by the most amount of people, and with the least amount of context.


Team rotations are a great tool employed by most companies, typically every quarter or two, which also requires putting a lot of thought into scheduling, skill sets, and impact analysis.


Whether learner or mentor, if somebody only has an hour to give, they can't spend it trying to find information, or scheduling a meeting with somebody who may not be free. We're really going to have to crack this nut to get our volunteer labs working effectively with such high team churn!


Luckily we all stand on the shoulders of giants, and an absolute master-class of working productively in a distributed, asynchronous environment comes from Matt Mullenweg's (CEO of Automatic and of WordPress fame) in his interview with Shane Parrish here. Hopefully we can build on that in a way which works for such a churn-heavy initiative!



12 views0 comments

Recent Posts

See All

Comments


bottom of page