https://ames.world/posts/shedlife/

As always the responses were great. This post summarises what I learned:

Onboarding starts way before a person joins a company.

If someone wants to work with you, they will be thinking about it way before onboarding starts. When people are looking for a new job, they want to know what a company is like to work for, almost as much as the salary and perks. No one wants to work somewhere that's not going to motivate them or make them miserable. Sharing how you work as a company gives candidates an insight into the sort of organisation you are, and whether they might want to work there. Blogs and videos about how you work and publishing your company handbook on the web are great ways to provide that.

Interviews are an important part of building a great experience. All too often it’s forgotten that interviews are a two-way process. The candidate is assessing your company too. If they don’t like what they see, they won’t accept, and worse still they’ll pass on their experience to their peers. At Surevine we try to make interviews as realistic as possible, but fun too. We run “Day in the life” interviews, a chance for a candidate to show how they would work with the team on a real-world scenario. The whole team then gets to know the candidate and see what they can bring to the team in a real practical sense. Most importantly, it gives the candidate a real insight into how we work that traditional interviews do not.

Finally, as Josh Abbot points out, all too often someone is successful and offered a job, and then they hear nothing but silence whilst they work off their notice, sometimes for months. This can be really disconcerting, so make sure to keep in regular contact. Use the time to introduce other people in the company to the new person in a way that's pressure-free and without expectation, they don’t work for you yet!

Josh Abbott on Twitter

@IanAmes It's a great point Ian and something thats often overlooked. Personally I think "onboarding" should start before your first day. All too many people now have 3 month notice periods and that time gap can cause all sorts of issues....

Make sure you use the time to get the new person setup on all the systems they will use, there is nothing more disheartening than starting a new role and not be able to access anything.

.-. --- --. . .-. / ... .-- .- -. -. . .-.. .-.. on Twitter

@IanAmes Get them set up on all the company systems before they get there. Makes such a difference to being able to get settled in the first few days.

The first day.

There was so much good advice given on making the first day a success. Luke R suggested making the first day a Wednesday to reduce the cognitive load of the first week, and to ensure they you aren’t distracted by the inevitable Monday interruptions:

Luke Radford on Twitter

@IanAmes Have found starting people on a Wednesday not a Monday helps. Day 1 meet and greet, Day 2 this is your role etc, Day 3 work at home and do mandatory training. Weekend to recover. 5 days in a new role is overload before starting

A strong trend was people wanted to know what the companies history, mission and strategy was and how they contributed to it, this was the most overriding theme in the feedback:

Simon Worthington on Twitter

@IanAmes "What are your/the high-level goals?" I want to know how you see the big picture, and also that there's high-level buy-in to solve it. Without that, it's often hard to do anything meaningful.

Akiko Kato on Twitter

@IanAmes - corporate strategy and other guidances, ''purpose'' - what they want me to do / expect from me (results, communication, way of working, tools to use etc), ''needs'' - org structure, who's who, team(s) to work with, anything that I should be aware, ''who''

Harry Bailey on Twitter

@IanAmes I like at lot of what others are saying. Culture, history, values. Communication channels and expectations. Security details like users / email etc and access to them. What you can say no to. Any regular meetings. Any team members with specific needs or preferences.

Trainual on Twitter

@IanAmes 1. Company history, values, culture & vision 2. Office tour - where everything is and how to use things like the fancy coffee maker! 3. Meet the team

This was closely followed by more pragmatic advice such as, where can I get good coffee, how do I communicate with my team, what are the unwritten rules of the company, and where are the toilets!

Stay At Home Bear on Twitter

@IanAmes 1. Where's good coffee 2. The important stakeholders (and politics/management lines) 3. Institutional blockers

Harry Bailey on Twitter

@IanAmes - The expectations of your output over the first couple of weeks. - Who you ask when you have a question. - office access and layout. Toilets, kitchen, meeting etc. All essentially hygiene items, but then 3 is nowhere near enough.

kim on Twitter

@IanAmes I want to know where people go to share info - we have yammer but not all teams use it so sometimes its a weekly email you need to look out for or a team wall or something (I'll learn stuff and get to know the namea/faces of people who also know stuff)

kim on Twitter

@IanAmes Who is in my team and who do we work with on a fairly regular basis. I know this is basic but have legit been in teams for months before clocking that I shared the same line manager with some one else

kim on Twitter

@IanAmes Tell me how I get stuff done. Are we an IM team or an email team. Do we do phone calls? eg Kim hates when you IM her always drop her an email and she'll phone you back kind of thing.

Fitz 🐝 on Twitter

@IanAmes @mclrnkim 5. Space for people to learn each other's capabilities, needs, preferences, and bits of lives ppl want to share 6. Commitments, red lines, cliff edges, no go areas 7. Brilliant basics-door cards, security passes, tea club, IT access 8. Clear, employee policies that meet needs

nicola_tallett on Twitter

@IanAmes What's the dress code? Do I bring my own coffee mug? What do people do for lunch? You'll tell me what to do, I want to know how to do it and what's the culture.

Ed Griffin on Twitter

@IanAmes Great question. 1. Time with each team member. 2. Systems & processes that will help me work. 3. Loos, coffee point/cafes, meeting spaces.

A great template for sharing the important day to day stuff with new starters is Sarah Carter’s induction trello board. I’ve borrowed this board a number of times, including at Surevine, and it saves me so much time remembering to collate the useful but small information that gets forgotten about once you have been somewhere more than a couple of weeks.

Each new person can make their own copy and refer back to it over time, and it can get constantly refined and improved based on feedback. I couldn’t recommend it enough. In fact, if you want good advice on anything recruitment or people based follow Sarah!

Buddying up.

There were a lot of suggestions to give people a buddy. Sometimes it can be intimidating asking questions of your direct report, even if you try to make it not the case. Having a buddy gives the new person someone they can ask the ‘stupid questions’ without fear of looking or feeling stupid. It helps them to get to know another face in the company too and to get a perspective that they may not get from you. It’s a great way to develop existing peoples leadership skills too.

Spending time with the team was high on the list, giving the team and the new candidate the chance to bond and get to know each other is really important. Going out for lunch together on the first day or week is a great way to form relationships without the distractions of the office.

leeeshaari on Twitter

@IanAmes Hey Ian nice to meet you. 👋 Coming from a big consulting firm, first the Timesheet, knowing your Gallup strengths and everyone gets a brother or sister to help you. 😊

Diane Reddell 🌈 💙 on Twitter

@IanAmes 1. Introductions followed by team lunch/evening social to get to know team members. 2. Introduction to the job role and project work, 3. Have all equipment needed for the job ready on first day. 4 Having a welcome buddy for the first couple of weeks.

Sophie Ashcroft on Twitter

@IanAmes Have some set tasks and training goals prepared, and a first day team lunch is always a good idea

I hope this post is useful if you are looking to improve your hiring processes, happily most of the suggestions were already implemented at Surevine, but we have made some changes based on the feedback to help improve our onboarding experience. If you are interested in working with us, check out our jobs page.

What would a great onboarding experience look like? was originally published in Inspect and Adapt on Medium, where people are continuing the conversation by highlighting and responding to this story.

I first came across Wardley Maps a couple of years ago through the medium book. I found it compelling, Simon Wardley has a lovely humble style of writing. He described how he went from ‘bumbling CEO’ to ‘having a vague idea of what I was doing’. That self-deprecating style just drew me in, and I found a lot I could relate to in my work. However, I could never get the hang of mapping and I hoped going to MapCamp would help me have that aha! moment.

MapCamp started bright and early at 08:45. Simon opened the event with a condensed version of his classic example of the battle of Thermopylae as described by that staple of business, the SWOT diagram. He highlighted how traditional business tools failed to provide a sense of space and purpose (movement).

If you haven’t come across a Wardley map before, it is a sort of value chain map on steroids, it starts at user needs and branches out down the chain to all of the components required to deliver that need. As with a value chain, the things closest to user needs are the most visible. However, what it also maps is where each of those components is in their lifecycle. By adding this detail, and the direction the component is moving on the map (are you, or your competitors, moving from being custom-built to a product for example) you are able to make decisions on the best approach to take to developing or managing the component and where to invest.

Simon quickly re-iterated the basics of a map, before introducing the first speakers, Dr Sal Freudenberg and Chris Adams.

Climate change and Mapping — Sal Freudenberg and Chris Adams.

Sal opened their talk by describing the extent of the climate crisis and the work she has been doing with Extinction Rebellion to raise awareness and push for action. Her talk was all at once terrifying and inspiring and set the scene nicely to introduce the work Chris has been doing to use maps to highlight what impact a strategy can have on climate change. He introduced two strategies, firstly identify components that can be commoditised, commodities are more efficient through economies of scale and therefore use less CO2

Strategy 2 is to actively green your service if you are already working out the cost to provide your service, then there are stats available from the ONS to work out the carbon cost. I didn’t catch the citation but Chris said that the ONS estimated that every £10,000 of cost has a 3.2-tonne CO2 cost. Therefore it is possible to calculate the environmental impact of your business and use a map to identify where moving components to cheaper provision, or specific green providers can have an impact on your businesses carbon budget.

Key insight. Chris raised the point that if developers were builders they are expected to know about things that are harmful to their customers, such as asbestos. Shouldn’t we have similar expectations of software engineers that we know the impact or potential harm of the tools and materials of their trade?

What is the best move? — Andrew Clay Shafer.

Next up was Andrew Clay Shafer, there were a few moments at MapCamp when I could feel my brain being stretched in new and unexpected ways, and Andrews talk was the first. I found his presenting style difficult, but that forced me to pay attention. I don’t confess to understand all of it, it was a sort of well-ordered stream of consciousness, and yet it is the presentation I made the most amount of notes on.

He started by talking about how a normal human can become fluent in a new language in 6 months, but most won’t because our needs are met — We only learn anything to the level we need.

There are two kinds of players:

• Players who want things to be better
• Players who want better for themselves

So play a different game based on the type of person.

Aha! Went my little brain, of course! I have a tendency to naively assume everyone wants things to be better (most people do in my experience) but thats not always the case. Also, my idea of better may not be the same as someone else's. Find out about who you are playing with before deciding how to play with them.

Andrew moved on to talk about OODA loops (Observe, Orient, Decide, Act) which was developed by Air Force Colonel John Boyd to improve aerial combat strategies. One thing Andrew said made my brain pop again:

Going faster without a model to measure against is useless

and most interestingly:

Sampling too much is spending time and resources you might not have, and may cause inaction.

The second point resonated with me, I have seen many projects get stuck in analysis-paralysis because the fear of the unknown has been more prevalent than choosing a direction and observing what happens. I think if I’m honest with myself often those measures have been derived on gut feel rather than alignment to any perceived strategy beyond the vision of the project, something to dwell on more (but not so much I move into inaction!!)

Key insight. Think about what your competitors are doing when producing a map, what gaps or opportunities do the directions they take present.

Open Source and Maps — Adrian Cockcroft.

Next up was adrian cockcroft who I was very excited to see as his work at NetFlix was some of the first things I read when moving my thinking from ITIL based robustness to Devops based resilience and responsiveness. Adrian is now at AWS and he described some of the working practices there.

There were a lot of ideas in there that I liked and have strongly advocated for myself, such as service-based multi-disciplinary teams and a ‘you wrote it, you run it’ culture. What I found most interesting was that they separated ‘Product’ and ‘Business’ as two distinct areas to integrate into the team, the responsibilities listed under ‘Business’ were ones I always assumed to be the responsibility of a delivery lead, it made me think more about where my role sits in other peoples perceptions.

Another subject that caught my mind was Amazon’s approach to reporting, reporting occurred weekly to the following schedule:

Monday — Service Team.

• Review last weeks operations dashboards.
• Review last weeks revenue/growth/goals

Tuesday — Groups of Services.

• Roll up the reviews

Wednesday — CEO/VP level view of everything.

• Review all operations, spin the wheel, learnings
• Review entire business revenue/growth/goals

My first thought was “jeez that’s a lot of reporting overhead, how do they find any time to get any work done?” There were three things in retrospect that I could see make this manageable.

Firstly as with software (and nearly everything), shorter cadences don’t necessarily mean more gets done, just that focus stays on what’s important. A weekly report would be much smaller in size than a fortnightly or monthly report.

Secondly, it was clear in the language that the team had responsibility for hitting their goals, this reporting wasn’t a report up and absolve responsibility setup.

Finally and most interestingly was the ‘roulette wheel of reporting’ at senior level. As with any large organisation, it’s impossible to be on top of all things all the time. The roulette wheel has all the service team names on it, every week the wheel is spun and whichever team is landed upon reports to senior management. This means all teams need to be prepared each week to report but reduces reporting overhead.

Key insight. I can see how the ‘trust but verify’ model of reporting could save a lot of overhead time but still provide assurances things are being managed the right way, its one to keep in mind as we expand.

Capability Mapping — Emily Webber.

Next up was Emily Webber describing her approach to mapping capabilities and skills in organisations. I’m privileged enough to have worked with Emily first hand when she helped the Delivery Community at Land Registry to map our capabilities and skills. The presentation was a good reminder of the principles and practices of building good communities of practice and there was a tons of practical advice.

Firstly Emily described the difference between skills and capabilities, the two are used interchangeably often but the distinction helps to judge where a person is in their development.

Skills are abilities that people can learn, develop and demonstrate.

Capabilities are the application of knowledge, skills and experience to achieve an outcome.

Capabilities can be assessed through 3 ‘lenses’, What capabilities does a person demonstrate individually, for their team, or for their practice.

These lenses can then be used to identify development needs for Now (0–6 months), Next (6–24 months), and Future (2–5 years). Individual and team needs are often easily identified but practice needs can develop in isolation and un-aligned to organisational needs without a community of practice. Communities of practice are a group of people in the same role, but may not work together day to day, for example all the testers in the organisation would make a sensible test community of practice, in that community they can share approaches taken to solve common problems, share standard approaches, and advocate for particular training or tooling needs.

Emily then moved onto how to identify the capabilities of a Community of Practice, in 3 steps.

Firstly, she asks, 3 questions of the group:

• What do you do day to day?
• What don’t you do that you think you should?
• What do you do, that you think you shouldn’t?

Secondly, she identified the themes, what are the common capabilities that emerge for that practice (and what are the practices that are being done by that community, which should probably be done elsewhere).

Finally, an assessment is done to discover, what skills are needed to do these things well. The assessment has 4 assessments for each skill and capability.

• I have no experience
• I can follow others
• I can do it on my own
• I can lead on this

and finally an indicator of whether this is an area the individual wants to develop.

By collecting this up, it's easy to see areas to focus deliberate practice, training, and recruitment for skills. In my experience this worked well at HMLR it gave us to focus as a community on common areas for development and allowed us to act as a collective to advocate for training. I have been thinking about how to apply this model to Surevine where our ‘communities’ are much smaller, usually no more than 2 or 3 people, I also wonder if applying some ideas from Wardley mapping such as visibility, and how developed a capability may be to help make decisions on how a practice may be developing and where to focus for future needs.

Key insight. Putting the good things I learnt with Emily into practice at a smaller organisation should be possible, but it will be interesting to see what different approaches we take to community development where our communities are single digits in size, and lots of people identify as ‘multidisciplinary’.

Mapping as a sensemaking practice within digital ecosystems — Roser Pujades.

Next up was Roser Pujades from UCL. Roser provided perhaps my biggest insight from the day. Perhaps because of the way that the Wardley Maps book is written (Simon, moves from unclear CEO to using mapping to understand the strategy and succeed) it's a very personal context, I always associated Wardley mapping as a personal, isolated activity. Amongst other things Roser made it clear that mapping is more powerful when done as a group activity, its a canvas to define a perspective and to be challenged and changed, the more knowledge and experience that goes into it the more accurate it will be.

Roser also proposed an extension to maps to show ubiquity, how many are providing this or working on this problem, seemed sensible although the prospect of 3d maps when I’m struggling with the 2d versions made my head melt a little bit!

Key insight. As with most things in life, mapping works best as a group effort, something I hadn’t thought about before.

Managing for Serendipity — Liz Keogh.

Liz Keogh is another personal hero, her excellent blog posts on Cynefin have really helped me get to a good understanding of the sense-making framework. I’ve personally found Cynefin easier to understand and use than Wardley Mapping, probably because in my day to day work I’m more involved in project delivery than strategy. Cynefin is a great tool to move beyond cargo cult agile and to use an appropriate framework depending on whether your project is obvious, complicated, complex, or chaotic. Having early conversations about this helps to pick an appropriate approach and avoids misunderstanding later.

Liz’s talk focused on the Complex domain, she used Ludicorp as an example. Ludicorp released a web-based MMO called Game Neverending, in it players could share photos and chat. This feature was far more successful than the game itself so the company pivoted and Flickr was born. Similarly the IM tool Slack emerged from the online game Glitch. These were both good examples of managing in a complex domain, where it is necessary to probe-sense-respond.

My go-to approach has always been to use the lean startup approach, formulate a hypothesis, build something to test hypothesis, analyse and change based on whether hypothesise is true or not. Liz introduced another brain warping moment, it is better to measure for coherence than a hypothesis.

What! Sacrilege! Hypothesis are the foundation of the scientific method, how can this be wrong, screamed my brain. But hypothesis assumes a certain amount of certainty, you need to know something about a system in order to make a hypothesis about it.

Liz described Coherence as “A realistic reason for thinking our probe might have a positive impact — a sufficiency of the evidence to progress.” Hypotheses generally measure one thing. If we change x we expect to see y happen. Liz’s point was in uncertainty it is necessary to be broader, it takes a number of probes (with associated hypothesis) to make sense in uncertainty, don’t rely on single measures and don’t be afraid of having just enough evidence to proceed, i.e. not every hypothesis needs to be successful to provide evidence to continue.

Key insight. Find more people to challenge my thinking!

Maps and Security — Mario Platt.

After lunch I went to the practical session on Mapping and Security it turned out to be another presentation rather than an exercise but none the less useful for it. Mario Platt talked us through how he had used maps to identify trends in infosec. It showed how maps could be used for skills mapping, which led nicely from Emily’s earlier talk.

Mario also used maps to show security trends, and showed how robust solutions were now primarily commodity services, I was surprised resilient solutions were mapped as genesis/custom-built, it feels like we have been talking about resilience > robustness for years.

Key insight. Security moves slow!

Maps and the UN — Mark Craddock.

I snuck out of the Maps and Security session slightly early to see Mark Craddock talk about the work the UN has been doing to use mapping in the UN to come up with a data strategy that aligned to the UN’s 17 sustainable development goals. Here the sheer scale of what Mark was describing, trying to get different data agencies from across the globe working towards common goals, really blew my mind, trying to get an organisation to work towards the same goals feels hard enough sometimes. Mark spoke about using mapping to think about business models in platform terms, identifying movement towards commoditisation to enable rapid innovation by focusing on the stuff that's core to what they do.

Mark gave an example of census costs in different countries, in the UK the forthcoming census has an estimated cost of £900m and only happens once every 10 years. Meanwhile, in Denmark, their citizen data is much better structured and managed so they can run the equivalent of a census with an overnight batch job (I paraphrase as I didn’t catch the exact time but it was days not years).

Finally and interestingly Mark introduced a way where you can help get involved in mapping parts of the UN strategy, something I’m going to look into as a way of practising Wardley Mapping, you can find out more at the UN Global Platform handbook.

Key insight. Platform thinking aligned to Wardley Mapping makes a lot of sense.

Beginning your mapping journey — Chris Daniel.

For my final session of the day, I went to the practical session led by a very lively and engaging Chris Daniel. He gave us a quick overview of mapping with some basic examples of where different examples would fall on the evolution scale. He then asked us to break into teams and map the ‘Perfect New Years Party.’

Our merry band quickly came up with the idea of providing a place to leave kids for a new years celebration, which seemed like a unique enough angle as most other teams were aiming at the adult market. We found quickly that most of our ideas fell into the commodity space and we got a little stuck at that point, but as we plugged away at it we started to think about what was likely to be our high costs areas, and how could we innovate towards reducing them, leading inevitably perhaps to IOT robot Carers on the Blockchain. Strategy Generator would have been proud!

Key insight. As I had started to learn throughout the day, doing the exercise as a group worked much better than my previous lone attempts at mapping. It became most useful after we had mapped what we thought the current landscape was and started to ask ourselves, so what next? A point I hadn’t reached before on my own, and where I suspect its real benefit lies.

Conclusion.

I hope this post gives you an idea of what MapCamp was about, I certainly feel like I learnt more about what mapping is, and more importantly some different approaches from where I was getting stuck, most obviously not doing it on my own. If you were there, what were your key insights?

Reflections on MapCamp 2019. was originally published in Inspect and Adapt on Medium, where people are continuing the conversation by highlighting and responding to this story.

3 months ago, I took the next step in my career and joined Surevine as a Team Lead. There were many things that first attracted me to the company, but one major benefit was that it’s totally remote, and so learning how to work collaboratively whilst remote was a challenge that really interested me.

Sureviner’s are spread all over the country, and my team alone covers a geographical area that stretches from Durham to Plymouth. Although I’m only 3 months in, you learn pretty quickly what works and doesn’t when it comes to remote work. Here’s what I have discovered:

1. Be specific about how you communicate.

By far the most important thing I’ve found about remote work is that it’s much more necessary to be specific when you communicate. It’s far too easy to misconstrue meaning without body language clues you get from face to face. Here at Surevine the very first thing we do with new starters is talk them through how we communicate. I’ve seen the same thing at remote meetups such as Agile in the Ether. Establishing ground rules at the beginning makes communication easier and more effective. The only thing that surprises me is that this isn’t more prevalent in traditional work environments. Effective communication is key to shared understanding whether you’re working remotely or not.

2. I’m so much more productive.

Working in your own space with very few distractions does wonders for productivity. I’ve previously found open-plan offices can ruin an agile team’s effectiveness, and when I used to work in an office I would regularly have to work late just to have space and time to get anything done. With remote working, I’m set up just the right way for me; we use statuses a lot to show colleagues our availability meaning that finding the time in the day to get stuff done is not an issue.

3. Sometimes, remote working just doesn’t cut it.

There’s no getting away from it, sometimes it’s just necessary to get together face to face. At Surevine we’re not shy about this. If it makes sense to get the team together, then we do. Booking travel and co-working spaces is simple, and we try to book spaces that are relatively central to the whole team. We have a policy of using trains as much as possible, as public transport is much better for the environment, but it also allows us to continue to work whilst travelling (in fact I’m writing this post on a train right now!)Because people are taking the time to travel there is much more commitment to making meetings a success — nobody wants to spend a couple of hours on a train for nothing. We prepare clear agenda’s with expected outcomes, for which I tend to use the phrase ‘We will know this agenda item is complete when…’.

On a day to day basis, we are just starting to explore how techniques such as mob programming could work remotely to help improve collaboration, although this needs to be balanced with keeping up our productivity. But as they say, there is nothing more useless than doing something efficiently, that shouldn’t have been done at all.

Once a quarter we get together as a company to collaborate, we call them RLMs (Real Life Meetings), which can seem rather strange, meeting someone in the flesh for the first time who you know well and work with day to day remotely.

4. Status updates can feel a little paranoid if you haven’t used them before.

Regularly posting what you are up to can feel weird at first, if you have come from a low trust environment it can feel as if you are being watched. Why does everyone need to know what I’m up to? What are you going to do with that data? That’s not the purpose of status updates, it's intended to show colleagues your interrupt-ability. If you’re free to take calls, set yourself to free. If you’ve gone to the kitchen to get a cup of tea, or really need to get your head down and concentrate, set an away status. It avoids your colleagues wasting time when you’re not available, and avoids you being interrupted when you need to focus.

5. Remember to have some fun!

Super productivity and laser clear meetings all sound great for a business, but not a lot of fun. I’ve found a few times that I have forgotten to add the human element to meetings. This runs the risk of de-energising the team and I’ve become more aware of the need to inject some fun into some meetings after all happy people are productive people. We have a few things we do at Surevine specifically: Nic, one of the other team leads, introduced a down tools session to just get together and hang out and get to know one another, which has grown and is now open to the whole company. On Friday’s we run ‘Techcellence’ a chance for Sureviner’s to come along and talk about whatever is of interest them, which, despite the name, can range from tech to history to food.

6. It’s easy to be distracted at home.

I have been surprised at how easily distracted I am, but it’s not uncommon. We regularly talk about techniques for getting down and focusing. Some folks like white noise, some like to use the Pomodoro technique, others (like me) like to visualise their work on a board and move things to ‘done.’ The difference from office work is that we actually talk about this stuff and look at ways to improve it. Offices are just as distracting, but rarely have I had a conversation about what I can do to make that better, it’s just accepted as part of office life.

7. Remember to get out of the house!

In my first few weeks, I found I wasn’t really leaving the house and I was getting irritable and restless. It sounds obvious, but I just wasn’t spending enough time outside. Now I aim to go for a walk around my local park before starting work, and often at lunch too. The fresh air resets my brain and helps me reconnect with the outside world.

8. One remote, all remote.

We find that when working with clients who are office-based, often remote calls become a group of people huddled around a laptop. The amount this affects effective communication cannot be understated, even with standalone mics. We, therefore, try to operate a one-person remote, all remote policy to make communication more effective.

9. There is no perfect video conference solution.

We use a whole bunch of VC tools because there’s no perfect one. Primarily we use:

• Google Hangouts — Generally easiest way to setup a VC with clients
• Slack calls — The pencil feature that allows everyone to draw on the screen is useful
• We used to use zoom which was excellent for being able to see everyone in the call, but the recent security bug has meant we have stopped using it.

10. Remote work makes it easier to inspect and adapt.

The best thing by far about remote work is that it’s more obvious when things aren’t as effective as they can be. Often in office environments, poor working practices and communication are accepted as the ‘norm’, whereas a remote company is wholly dependent on effective communication and working practices . This forces remote teams to pay more attention and to adjust and improve. This results in teams who are extremely effective at working together and getting things done.

The 10 things I learnt from remote working was originally published in Inspect and Adapt on Medium, where people are continuing the conversation by highlighting and responding to this story.

Day three and as expected life is disrupting the schedule. A work trip to London and DIY has meant falling a bit behind on writing up what I have learned, so this is a bumper edition!

Variable Resistors.

Variable resistors are also known as Potentiometers (or Pots for short) are as their name suggests devices that allow you to change the resistance of a circuit. They look like a dial, and that is exactly what they can be used for.

They work by having a ‘wiper’ of carbon that as you turn the dial introduces more or less carbon into the circuit. The more carbon, the higher the resistance and vice versa.

Patterns and Robotics: A Complex Reality | Data Driven Investor

AC and DC electricity.

Electricity is basically the flow of electrons. In day one we learned how the flow of electrons is measured in amps. For DC electricity that ‘flow’ is one way only, the current flows directly, hence DC stands for Direct Current.

With AC electricity, the current alternates (can you guess what AC stands for!) the flow of electricity changes regularly from positive to negative in a wave pattern.

Capacitors.

At the risk of revealing my age, I can’t help hearing the word capacitor and not visualizing Marty McFly and Doc Brown (Transformer has a similar effect) but I digress. Capacitors as the name suggests, store electricity (they have electrical capacity). Our friend Ian Juby shows us how to make a capacitor with two sheets of tin foil, and two sheets of wax paper wrapped up into a cylinder. It’s a good exercise as it demonstrates what a capacitor is.

A capacitor is two large metal surfaces, with a resistant surface in between. If you attach one metal surface to the positive supply and the other to the negative, electrons flow onto the metal surface attached to the negative supply, but can't get any further. This results in the metal sheet saturating with electrons. Similarly, on the metal plate on the positive side, electrons are repelled off the metal service to the positive supply.

If a capacitor is hooked up to a DC supply, and you measured the current it would show a big spike in current as the negative plate fills up with electrons, followed very quickly by a reduction of current to zero as the electrons on the positive metal plate are repelled. This means that DC current very quickly cannot pass through a capacitor.

If a capacitor is hooked up to AC supply the same thing happens initially, the plate on the negative side spikes with current and starts to drop, however as the polarity of the current switches, the current spikes again.

What this means is that capacitors allow AC current, but block DC current.

Capacitance is measured in Farads (F), but they are usually very small, in the micro, or nanoscale.

Diodes and LED’s

A diode is not dissimilar to a capacitor. It is made up of two plates of silicon that have been ‘doped’ one with excess electrons (the cathode), and one with fewer electrons (the anode). When the two pieces are welded together, there is an area between the two where the electrons balance out. The is called the depletion zone, and it has very high resistance (see day 2).

If you attach the positive side of a circuit to a diode and the negative to the anode, the electrons in the cathode are drawn towards the positive feed causing the resistance zone to get bigger and more resistant, ultimately preventing all current in the circuit.

However, if the circuit is reversed and the positive is connected to the cathode, and the negative to the diode, the positive current repels the electrons in the cathode, making the resistance zone smaller and less resistant.

This means that a diode only allows the flow of electricity one way. Diode’s are also only capable of passing through the voltage it is rated at, if more voltage is applied, it heats up and will eventually burn out so protecting them with resistors is vital.

But if a diode only allows the flow of electricity one way? What happens with AC electricity? As expected it would block the flow on the positive wavelength, and let it through on the negative. It is possible to configure diode’s to convert Ac electricity to DC electricity. The is called a bridge rectifier. The gif below shows how it works.

An LED is a Light Emitting Diode. The resistance zone gives off excess electrons in the form of light rather than heat.

#100DaysOfRobotics — Day Three and Four. was originally published in DataDrivenInvestor on Medium, where people are continuing the conversation by highlighting and responding to this story.

So I left day one rather abruptly, with a resistor color chart and not a lot of explanation. This was for two reasons:

1. I didn’t fully understand it.
2. It was taking me almost as much time to write about what I had learned on day one than the time I had spent learning.

Patterns and Robotics: A Complex Reality | Data Driven Investor

I’m aware that these two points are contradictory. If I can’t explain something well enough in a blog post then it doesn’t hurt to go back over the subject to reinforce my own learning. I’ve found before that writing about what I’m learning is really useful for that knowledge to sink into my brain, so I shouldn’t be afraid to go a little slower and do a little less. Quality learning, not quantity learning.

So back we go to:

Calculating resistor values by their color bands.

I’ve been confused by resistor bands before. A few years ago I bought an Arduino kit which had loads of cool components and very patchy documentation. I had never used resistors before and I didn’t understand how the color codes told me anything useful. Luckily they came attached to a piece of tape with the resistance typed on them and I studiously attached them back to the paper after use or I would have been doomed.

If you haven’t seen a resistor before they look like this:

The colors all represent the resistance value of the resistor (because how hard can it be to write it on!) Even more confusingly some resistors have 4 bands, whilst others have 5. Let’s start with 4 band resistors.

In theory, it should be obvious which way is left right on a resistor because the gap between the third and fourth band should be larger than the gap between the first and second band. As can be seen in the image above this isn’t always the case, but go with me. The image below shows a 4 band resistor and what each band represents.

The first band is the initial value so in the image above that is red, which equates on the chart below as ‘2’.

The second band is purple, which equates to ‘7’.

The third band (on a 4 band resistor) is the multiplier, or how many zeroes to add after the first two number. In the case of the image above, green represents a value of ‘5’.

The fourth band is the tolerance. Few electrical components are 100% accurate, the tolerance tells you what range of resistance the capacitor will work within. Gold represents 5%, Silver 10%. No band equals 20%.

So the example resistor has a resistance value of 2,700,000Ω or 2.7MΩ

In the case of a 5 band resistor, the additional band just introduces an additional value, and the multiplier moves one to the left. In the case of the resistor shown below:

• Band a is brown so equals 1.
• Band b is green so equals 5.
• Band c is red so equals 2.
• Band d is black so equals 0.
• Band e is gold so equals a tolerance of 5%

So it is a 152Ω resistor with a 5% tolerance.

What’s the point of having a multiplier of 0 you might ask? Why not just show the values? In the case of a 5 band resistor then it would easily be confused with a 4 band resistor if the multiplier wasn’t represented. If the d band wasn’t shown it would be mistaken for a 1500Ω resistor.

Hopefully, that explains resistor bands a bit better and you don’t end up frying your circuits or being terrified of storing your resistors for fear of never knowing what their values are in the future. Finally, let’s see if I can calculate the values of six the resistors in the first image.

Going from left to right:

• Resistor 1 has a value of 39000Ω or 39KΩ with a 5% tolerance.
• Resistor 2 has a value of 47Ω with a 5% tolerance.
• Resistor 3 has a value of 1500Ω or 1.5KΩ with a 5% tolerance.
• Resistor 4 has a value of 100Ω with a 5% tolerance
• Resistor 5 has a value of 2200Ω or 2.2KΩ with a 5% tolerance
• and Resistor 6 has a value of 47000Ω or 47KΩ with a 5 tolerance.

Did I get them right?

#100DaysOfRobotics — Day Two. was originally published in DataDrivenInvestor on Medium, where people are continuing the conversation by highlighting and responding to this story.

Summer 2019 is coming to a close and there are a mere 127 days left of the year. So I have decided to set myself a challenge. I’ve seen plenty of people doing #100DaysOfCode (and to be honest I probably should) but I wanted to pick a challenge that lets me get a bit more hands-on, I’ve always like hardware just as much as software and I’ve tinkered with a few robot kits with the kids and wanted to learn more. So I have decided to set myself a 100 Days of Robotics challenge.

The rules.

Usually ‘100 days’ challenges are 100 continuous days, I know myself well enough to know that life will get in the way of meeting me achieving 100 continuous days of anything! So instead I’m going to aim to be done by the end of the year (127 days). Realistically December is usually a write off for anything so I’m going to have to stay close to the everyday target just to have any kind of leeway in December.

In order for a day to count, I need to have completed an hour of ‘something to do with robots.’

Patterns and Robotics: A Complex Reality | Data Driven Investor

I will blog about what I have learned each day, buts its ok to bundle days up into one blog post, as long as this doesn't exceed a week.

Getting started.

I was really surprised that #100DaysOfRobotics and #100DaysOfRobots are pretty much a wasteland on twitter. As my knowledge is fairly basic I thought I would start with a Udemy course to at least get down the foundations. I chose Electricity & electronics — Robotics, learn by building by Ian Juby because when I have been faffing around with robots and RC vehicles, my electronics knowledge has been my weak spot. Also the presenter Ian Juby looked like he was having a lot of fun putting together the course, and finally it was on sale!!

Day One. Voltage, Current and Resistance.

I was right Mr Juby is a great presenter, his presentation style could probably be described as ‘jokey Dad’ but its engaging. He started off by making sure you’re aware of the risks of dealing with electricity in a fair bit of detail (not gruesome detail) for example what would happen if you shorted a car battery, or walked into an electricity substation.

Next, he described two types of material, conductors — materials that allow electricity to flow through them, and insulators — materials that don’t allow electricity to flow through them. At this point, GCSE science flashbacks were starting to set in, but it’s a very long time since I did them, so no bad thing.

Finally, we moved onto the terminology:

Current is the measure of the flow of electrons (what electricity is) and is measured in Amps, represented in equations by the letter A (or sometimes, confusingly I).

Resistance is the measure of, well resistance, how well (or not) electrons flow through a material. Resistance is measured in Ohm’s and is represented in equations by the Greek letter Omega (Ω).

Voltage, I still struggle with exactly what it represents. Ian Juby used the analogy of a garden hose. Current is the flow of water, Voltage is the pressure of the water, and if there was a kink in the hose, that would be Resistance. For now, that's good enough for me. Voltage is measured in Volts and is represented in equations with the letter V.

Ohms law defines the relationship between these three properties. It states that the current through a conductor is directly proportional to the voltage between two points, or put more simply. Current = Voltage divided by Resistance.

I = V/R

this means we can also work out Voltage and Resistance of a circuit if the other two values of the Ohm’s law triangle:

Resistance in Series circuits is easy to calculate when you have more than one resistor in the circuit. The resistance compounds itself, therefore you just add the ohm values of each resistor together.

Resistance in Parallel circuits is a little bit more complicated. The flow of electricity is divisible through each parallel circuit. Therefore to calculate total resistance (Rt)

1/Rt = 1/R₁ + 1/R₂ + 1/R₃ … + 1/R𝗑

Where R₁, R₂, R₃, R𝗑 are the resistance values of the resistors in the circuit (however many that may be).

Finally, we went over calculating resistor values by their color bands. To be honest I need to go back over this section, but for now, here’s a color chart from the internet!

#100DaysOfRobotics — Day One. was originally published in DataDrivenInvestor on Medium, where people are continuing the conversation by highlighting and responding to this story.

Given so much has been going on and I’m a bit rusty I thought I would go back to Richard McLean’s excellent 20 question format. Seeing Richard today at Agile in the Ether and getting excellent communication advice from him reminded me that I don’t think I have ever read any of his posts that hasn’t made me think “yes that's a great idea” or “huh, that's really interesting I hadn’t thought of that.” If you haven’t read his stuff, check it out.

So here goes:

Who or what inspired you?

As has been the case since joining Surevine I have been blown away by the people here. Working every day with intelligent people who care deeply about doing a good job is so inspiring. Every day I am in a conversation about what we could do to improve and every Friday we have a weekly meeting called Techcellence where we lean coffee ideas and themes. It just gives me so much energy.

Who did you work with in a different profession/team within your organisation?

The nice thing about working in a small company is that I am working with people in different professions or teams every day. This week I have been working with Laura in Talent Management about recruitment and onboarding; Raph from Operations to iron out some reporting invoicing issues (thanks Raph) and Nic and Dom from Team Mercury to assist in a Day in the Life (DiTL) for a new team lead.

Who did you work with/talk to/visit outside your organisation/sector?

I’m working every day with clients in Government, this week I was up in Whitehall for a day for a couple of workshops. I can’t really go into much more detail than that.

What did you enjoy?

I have enjoyed trying to get my blogging juices going again. I’m exploring Cynefin as a way we can improve our early engagement in projects. In order to make sure we are aligned with our clients on the sort of problem it is we are tackling and agreeing the most appropriate way of delivering the outcomes. It feels like it has legs and writing it as a blog post describing how it could work has helped me think about how to apply it in practice and what potential issues there could be. It isn’t finished yet but getting back into the practice of thinking by telling stories has been really enjoyable this week.

What was fun?

Day in the Life’s are always fun, this was the first one I had done remotely and I got to role-play the customer. I gave Nic, the other team lead, kittens apparently! They are a very human way to interview people, but they can be disconcerting if you haven’t been through something similar before.

To answer the question What could have gone better? We can be clearer with candidates about the purpose of DiTL and the outcomes we are looking for. Sometimes candidates can get stuck asking us to describe our working practices when what we are looking for is how they would tackle the scenario, what has worked for them in the past and how would they approach it. It’s something we are aware of and improving. Despite this it went well the candidate was successful and has accepted an offer, hooray!

What would you have liked to do more of?

For a variety of reasons, I have missed far too many standups this week. Standups are really important in remote companies and I’m disappointed with myself for missing them. Dave and JB have done an awesome job of being self-organising and covering them though.

What do you wish you could have done less of?

Meetings. Dan described my calendar this week as hilarious. I wouldn’t mind but a lot of the meetings didn’t have a clear agenda and outcomes, which really annoys me. I’m thinking of introducing something like LoMo templates. I haven't used them before but structure encourages good meeting etiquette. I would be interested in hearing from anyone who has used them or anything similar.

What do you wish you could have changed?

Meetings, see above.

What was hard?

Visualising work. I still hate Jira.

What went well?

Day in the Life (see what was fun?).

What could have gone better?

Day in the Life (see what was fun?)

What (outcome) made you proud?

I’m really pleased with how my little Kudos slack reminder on Friday’s has taken off, it’s really nice to see colleagues thanking each other for their support over the past week.

When did you make a personal impact that improved something?

Hopefully, we will be bringing in an agile coach for our client soon. Someone I have sought out and recommended. I’m looking forward to them starting.

What did you achieve?

I always find this one hard to answer, so much of what I do is small, helping others to try something new, recommending a different way, making sure people are as happy and supported as I can make them. The achievements can be difficult to judge and slightly intangible.

What did you do that was critical to something succeeding?

Taking part in the DiTL quite late on and pretending to be a customer on a project I hadn’t been involved in before was a bit of a learning curve. Luckily it gave me something to do on the train back from London that wasn’t overly dependant on wifi!! Why is it so hard to get good wifi on trains? Surely a series of cell towers along the line would do it?

What did you do that helped someone else achieve something?

This is an interesting question. I have been having to get used to delegating more, my time is just too stretched, but I’m not thinking about this in terms of giving someone work that they can view as an achievement. I need to flip this mindset.

What did you fail with?

Simplifying things. I’m still struggling with the art of maximizing the amount of work not done.

What did you learn?

I’ve been reading more on cynefin as mentioned in what did you enjoy? This excellent post from Liz Keogh was recommended by Emily Webber at her ever excellent Agile in the Ether meetup. If you haven’t heard of cynefin before it’s a great primer

What did you experiment with?

I’ve been camping out in a co-working space for the last couple of weeks whilst our kitchen and bathroom get’s rebuilt. I have noticed I’m not quite a digital nomad yet, I’m missing my post-it kanban board. I need to get the hang of working more electronically. We are also staying at my father-in-laws house so I’m back to commuting because his wifi is so bad. Not being at home and not having a workspace is very discombobulating.

What are you looking forward to next week?

Spending more time with the team, reviewing our branching and releasing strategy.

In other news.

Week off with the fam last week whilst the building work started. The best thing about living in the south west is it’s always like being on holiday! #SouthWestIsBest

Weeknotes. wb 16/08/19 was originally published in Web of Weeknotes on Medium, where people are continuing the conversation by highlighting and responding to this story.

What went well?

The week started well, I was up in that London again for a roadmap session with the client. As with all planning, the value isn’t the plan itself, it’s in the conversations and shared understanding. I certainly came away clearer about the longer term objectives of the project and where we fit in the delivery of those objectives.

As mentioned last week, I tried some new things, I published my user manual of me on the company wiki and left a template for others to do the same. I also setup a slackbot reminder asking if anyone had any thanks they wanted to give to other people in the company. #KudosFriday took off in a big way which I was really pleased to see, it was a nice thing to end the week on.

We had a new person join the team and I have shamelessly ripped off Sarah Carter’s induction board for our own use. I’m hoping it helps guide them to useful stuff quickly and its a cheap test to see what is useful, what is missing and what didn’t help, or wasn’t clear.

The frontend developers tried out mob programming this sprint. Feedback from the first attempt was that they didn’t write as much code as they expected but they all came away from the first session with a much clearer shared understanding of what needed to be done to deliver the stories they were looking at. I’m really pleased that they gave it a try and plan to do it again, it seems like such a great idea for a remote company in so many ways. It builds an understanding of what needs to be done (I think it could be even better with product owners and testers in as well to answer questions as we go), it’s a nice balance of deep work but with team collaboration, and it helps people get to know one another and how they work. I’m definitely going to look into it more and see if I can help make it a success.

What could be better?

As I mentioned above I introduced the user manual to the company and had a very good chat about it with one of the sureviners who wasn’t comfortable publishing theirs in confluence. I had made an assumption that being open about how you like to work would be ok, I was wrong and I was really pleased we had the conversation. Previously when doing the manual it had been in project kick-off events where only the project team saw the output and it worked really well. I hadn’t thought through what was the best way to do the exercise in a way that makes people comfortable in a remote environment. More thought needed.

Our backlog is getting a little out of control, there is a lot being defined based on the current paper process when we haven’t fully sussed out what a good digital flow would look like yet. Its a difference of point of view, I suspect it is being viewed as a simple change (put the paper process online), a series of known changes that need to be made as quickly and effectively as possible. The reality is it is a complicated change, putting forms online rarely works, they need re-designing for that medium, there are known unknowns and therefore the way we approach it needs to allow for discovering what works best. Changing points of view can be challenging.

As I mentioned at the beginning, time has got away from me a bit this week. I don’t think I have missed anything urgent but I’m aware I have been responding to things rather than following my plan for the day, after how well last week went I’m a bit disappointed this has been the case but I shouldn't be surprised in the what is effectively our first sprint. One to watch but not beat myself up about.

In other news

Got out on the paddle board on Thursday for the first time in ages with some good friends. It was a perfect evening, sunshine nice clean waves, warm water loved every minute of it and have already made plans for doing the same next week.

Friday was the regular agile in the ether meetup. The topics always really resonate with me and its great to share or listen to other peoples ideas. I also got to run a warm up session using my retro 70’s thinklinks cards which was a lot of fun. Topics included “bridging the gap between agile teams and waterfall governance”, and “who is the best line manager you have ever had and why”.

Weeknotes wb 17/06/2019 was originally published in Web of Weeknotes on Medium, where people are continuing the conversation by highlighting and responding to this story.