During the DevExperience conference on the 25th of March, we sat down with one of the key speakers, Lisette Sutherland, to discuss the ways in which technology advancements, and VR in particular, will impact people’s lives and working habits.
Beaglecat: Could you please tell us something about yourself and the company you run?
Lisette Sutherland: I am the director of my own company, Collaboration Superpowers. Myself and other licensed Facilitators give online and in-person workshops to help companies work better together remotely. I am also the remote team manager at a company called Happy Melly – a global network of businesses that are focused on making people happier at work (included are Management 3.0, my company, LeanChange.org, Improv Agility, and others).
BC: Do you think in 5-10 years we will have offices like we have today or do you think everyone will work remotely?
L.S.: Technology is making the traditional ”9 to 5” schedule unnecessary and less attractive for more and more people, especially the younger generation. The most important thing is working from where you are the most productive. Some people work better on the road, some at the beach, some from the office, some from the comfort of their own home – everyone should choose what works best for them.
BC: Do you think that we will be able to work using Virtual Reality in the near future?
L.S.: They’re already doing it. Virtual worlds have existed for more than 20 years now. People are going to school and earning degrees in VR. People are going to conferences in VR. The military uses VR for simulations.
The only issue is that navigating in VR is very difficult, it’s like learning to play the piano. That’s why it’s not so popular. It’s worth trying it out to see what it’s like to be in a virtual world. For example, you can create an account in SecondLife. When you log in, you are placed on a “newbie beach”, literally a beach for new people. Then you have to learn how to move your character and interact with the world and find your way to the place you want to go (like a conference).
BC: I am guessing that 10 years from now this is going to grow. How do you think this is going to impact us?
L.S.: One thing to be careful of is getting enough real life social activity. Technology has an addictive, unhealthy side to it. Each person needs to create healthy boundaries for themselves. The exciting thing is that with technology people can get together from anywhere in the world and solve interesting and challenging problems. I used to work for a company that was developing an online project management tool. The CEO was building it because he wanted to solve the problem of aging. He was frustrated that longevity scientists all over the world couldn’t properly collaborate together and easily share data. So he set out to build a tool they could use to collaborate at a distance. For me it was an ‘aha’ moment. I realized that if we could get the right people together, we could do great things like curing cancer or stopping global warming, or aging.
BC: What do you think the world will look like in 20 years?
L.S.: It is hard to say because if you asked someone 20 years ago what the future would look like today, they would have probably envisioned it completely different.
I recently held a workshop in Lebanon from the Netherlands using a robot – so I beamed into Lebanon, talked to the people as if I were there in the room. Drivable robots are also available now. For example, my friend from Canada beamed into one of these robots in Las Vegas, I beamed into another one from the Netherlands, and we both attended a conference as if we were in Las Vegas together. We visited booths, saw a presentation, had tea together, all from the comfort of our own living rooms. If you had told me I’d be doing that 20 years ago, I wouldn’t have believed you.
When borders dissolve, the possibilities really start to open up. For example, someone in Romania can work with a team in San Francisco, or a team in Vietnam. Sometimes you need that one guy or girl with that unique skill that nobody has – and what if that girl is not from the city you are working in?
There are also many people in the past that have been limited by location. For example, military spouses, disabled people or retired people. Military spouses have a hard time finding stable work because they are constantly moving. And there are many people who have retired, but still want to practice their craft or continue working somewhere. Because of remote technologies, there’s a whole new pool of people to choose from for the work that needs to get done.
BC: So do you think that in the future robots will do everything?
L.S.: I think robots should do the boring work and humans should do the interesting work. And maybe in the future not everybody will have to work full time, and maybe that’s ok. Do we have to work 40 hours a week? Why? That was a random number set by Henry Ford. Maybe we could work 20 hours a week and the rest of the time we could travel, or work on our hobbies, or spend time with our family, or just do whatever we want.
BC: What do you think is the influence of technology on productivity?
L.S.: Recently, I see a lot of companies struggling to go from being time-oriented to results-oriented. When we can work from anywhere, the focus is more on what you get done, not how long it takes you to do it. Spending the whole day at the office only means that you spent the whole day in the office, not that you were productive.
Summing up, the good thing about technology is that it dissolves borders but it requires a new way of working. What it means to be “present” at work is changing, and it’s opening a lot of new opportunities. A lot has happened in the last five years. I encourage people to explore some of the new tools and think about how they can use it in their own lives. My Work Together Anywhere Workshop is a great place to start.
Lisette Sutherland is Director atCollaborationSuperpowers.com, a company that helps teams work together from anywhere. She is also the remote team manager for the all-remote freelance team at Happy Melly.
Rejecting roles
Rejecting roles: That’s marketing’s job. You need to talk to IT.
Having roles is considered essential by most organisations. We’ve read dozens of business blogs, HR advice articles and even management training courses that insist clearly defined roles lead to better results, greater productivity and higher motivation. Without clear definition of roles, they warn that tasks get missed, no-one takes responsibility, the office is chaotic and individual motivation drops.
We disagree.
The writers of this advice have grasped the outcomes they want – people taking pride in their work, everyone focusing on delivering value, individuals coordinating and collaborating – but they’ve applied the wrong solution.
They’ve confused roles with responsibilities.
That may not sound like a big deal, but we think it is. Rigid role definition has some major downsides. We believe it hurts companies and individuals, costing them in creativity and happiness.
Most organisations intend their role definitions to be a way of signalling particular specialisations, expertise and responsibilities… but instead, the definitions swiftly harden into barriers, marking out territory which is defended against ‘interference’ from others. Have you ever been told to back off by the marketing manager for commenting on the new advert? Been refused access to the code base by the developers, ‘in case you break something’? Been told to leave presentations to ‘the sales guys’ or forecasts ‘the finance guys’? At the extreme, you may have your opinion rejected with a straight-forward ‘well it’s not your job to worry about x, it’s mine!’.
Individuals may also use their role definition as a way of avoiding unpleasant or boring tasks. This ‘that’s not in my job description’ approach ends up making the company less efficient as well as eroding team motivation. I remember organising a last-minute marketing stunt when I worked at Unilever. I was booking a double-decker bus to turn up and I wanted to check it would actually fit into the office forecourt. The marketing assistant nipped down to Reception to check. An hour later, she returned. The security guard had refused to measure the gateway and if it was beneath the dignity of a security guard, then she reckoned it was beneath the dignity of a marketing assistant as well. So I borrowed the security man’s tape-measure and checked the gateway (you could – quite literally – have fitted a bus through there). Anything wrong with doing my own measuring? Absolutely not. Anything wrong with wasting an hour of time arguing about whose job it was? Plenty.
Roles are comfortable – but bad for us
It’s very human to defend our own work and our own opinion. When we can dress this up with the authority of experience, expertise and organisational separation – all the better. Except it isn’t. Rigid role definition acts as a barrier and can stifle innovation. It can also make things slower and less efficient.
If a customer rings up with a problem, they want a solution, not to be told that only part of their problem can be dealt with by this department, and they must be passed on to billing or whoever to deal with the rest of it.
It’s not great for individuals either. Sticking to just one thing may mean our knowledge gets deeper, but also narrower. We can get bored or worse, so convinced of our own expertise that we can’t take on other points of view.
Being Radical: Sticking to the start up way
In many start ups, a lack of defined roles is the default position. There is not enough money to hire specialists – instead developers must learn to present to investors, marketing managers must be able to create and manage their own customer data, and everyone must have a grip on the financial assumptions as well as a grasp of the their product (this often means some grasp of the technology).
When entrepreneurs look back on the early stage of their companies, they often comment on wistfully on the diversity of work and of how close to the customer it meant they were.
Jeff Bezos, CEO of Amazon, recalled being the ‘mailroom grunt’ in the company’s early days, driving books to shipping and courier companies in his 1987 Blazer. But this doesn’t scale, right? Jeff Bezos is not still doing deliveries. Actually, he is. He spends a week every year in the warehouse. It’s not a PR gimmick, because he refuses to set up interviews when doing it. It’s an opportunity to stay connected to his responsibility – leading Amazon – and not the role of CEO. That includes really understanding conditions for employees – something for which Amazon has received a lot of criticism – and staying close to core services like order fulfilment.
Another trick used at Amazon is to have individual employees who have no role at all. Bezos has ‘shadows’, people who simply follow him around. It means there’s always someone free to chase a wild idea or set up an experiment – and it recognises that a responsibility like ‘envision Amazon’s future’ requires several people, not just a single role.
So what should we do?
1. Responsibilities not roles
Some radical companies go for a very broad responsibility ‘provide value to the company’ and say that how this is fulfilled is up to the individual. Others go for more precise responsibilities: ‘help the customer’ or ‘make sure we comply with financial regulations’.
The point is that how you fulfil these needs can require doing tasks which, in other companies, would be seen as belonging to differing roles.
2. Trust people
A lack of roles makes people more responsible, not less. Tasks rarely get missed because everyone knows they have total responsibility for the work – no tester will come pick up the programmer’s bugs; no finance controller will correct over-optimistic projections.
3. Trust people some more
A lack of roles doesn’t mean that everyone will try to do everything. People naturally gravitate towards what they’re interested in and what they’re good at. If someone is convinced she’s a brilliant illustrator and everyone else insists the stick men cartoons are rubbish, she will soon stop.
4. Value dissent not consensus
No roles doesn’t mean you have to design by committee. Heated arguments are common, and that’s fine. Even if people don’t agree at the end of the debate, the important thing tends to be to air the problem. Opinions can be rejected; a decision can still be made, risks can still be taken…
By: Helen Walton from Gamevy
Great Leaders Ask Great Questions
For the last few years, I’ve been working with and studying some of the best teams in the world; Red Arrows teams, SAS and US Navy SEAL units, Racing yacht crews, a Formula One pit crew, etc. I set out to study teamwork. In particular, I wanted to know how these teams have become world class. In the course of my studies, I identified six common characteristics, which differentiated these incredible teams.
Interestingly, I didn’t set out to study world class leadership. However, when I found world class teams, I also found world class leadership (I know, I probably should have expected that!). So, as well as studying teamwork, I also began to look at the characteristics that differentiated world class leadership. One of the most powerful insights that I discovered is this…
Great Leaders Ask Great Questions.
In fact, the great leaders that I encountered often didn’t provide any answers! Instead, they realise that the group has the potential to generate a better answer than they could on their own. It’s a principle that James Surowiecki outlines in his book, Wisdom of Crowds. When I shared this idea at an educational conference last year, a Head Teacher responded by saying, “That’s rubbish. Are your trying to tell me that Einstein should ask his class for the answer, and that the class will have a better answer than Einstein?”. “No”, I said, “Einstein is part of the class. So by engaging the class you get Einstein plus the class, not instead”.
Knowing that great leaders ask questions is one thing. Knowing what constitutes a ‘Great Question’, is another. So, what makes a question ‘Great’?
Here are some of my thoughts and reflections…
To me, ‘Great Questions’ are simply the right question, asked at the right time. To ask great questions, we need to understand the problem we’re trying to solve and where we are in the process. Do we need to ask a strategic question, or a tactical question, or one that’s related to implementing and executing a plan?
Strategic Question – Why?
Tactical Questions – What? …. How?
Action & Implementation Questions – Where? …. Who? …. When?
Very simply, it makes sense to understand why we are doing something (and whether we should be doing it), before deciding what we’re doing or how we will do it? Equally, it makes sense to know what we’re going to do, before deciding who will do it, when and where.
To me, ‘Great Questions’ are also well defined and simple. Sometimes it takes time and thought to frame a question well. The world class leaders that I saw at work often ask simple questions, which engage their team to collectively solve a problem. Some of the most powerful questions I’ve heard simply begin with the words, “How could we…?”.
To find out more, read Stronger Together; How Great Teams Work and hear from world class leaders sharing their wisdom on Be World Class TV.
By: Simon Hartley, Founder of Be World Class.
Nine things I didn’t know nine years ago
It’s coming up on nine years since I first started slinging code in a professional setting. Professional here meaning with a salary, in an office, with other engineers, decent coffee and unreasonable deadlines.
Back then I was barely newly minted from school, and what I lacked in understanding I certainly carried in hubris. I remember being vaguely offended not to be on the list of Sweden’s top coders that year. No idea how they would’ve found me, but I still remember being annoyed by it.
What I’ve lost in hubris in the last nine years, I’ve gained in experience. I thought it’d be useful to punch down a few things that it would have been nice to know nine years ago — maybe it can help you, if you’re just about to take your first steps out of school.
In no particular order, here are nine things I wish I’d known when I started out:
- Experience counts for something. This is obvious, and maybe a bit condescending. But I remember the first time I saw a colleague in a live, heated situation pull up YourKit and hone in on the fact that we’d have two ServerInstanceFactories, not one, and that caused the entire app to go belly up. Or when I got literally smacked on the fingers for not using two-phased locking correctly. And a thousand other things. My first two years of working, what I mainly learned was that I basically didn’t know shit.
- People are messy. I’d love to know how many hours humanity as a total spends every day mediating between two or more angry 40-year old men. Most of the time, you’ll find reasonable people that don’t share your point of view on things, and you are not obviously right. There are tradeoffs. And sometimes people hold on to stupid ideas longer than they should, simply because they’re people. It’s a great irony that software development demands literal, logical, unambiguous reasoning while being complicated enough that you need to collaborate with ornate, arbitrary, ambiguous humans.
- You’re not logical, you’re biased. If there was one thing I was certain of was that I reasoned with logic and soundness and that I thought things because they were true. Things such as — we hire people only because of merit. Obviously. What I’ve learned is that any point can be argued from many angles, and who I am, where I was raised, what I studied and who my friends are all influence what I think is obviously true. I’ve also learned that I’ll likely never be Spock, and that the only reasonable defense is to invite different points of view, and accept that reasoning from different premises can lead to different conclusions, and still be logical and sound.
- You can use engineering for other stuff. As a flipside to above, I’ve also learned that the method of engineering that you learn in school and hone over the years is useful for a ton of other stuff than just programming. What engineering is to me is a way to define, decompose and reduce a problem space, and from that reason a solution under balanced constraints. Really, figuring out what you’re asking, and then answering that. And turns out that anything from sales, marketing, finance, design to analytics are super-susceptible to this. Don’t be afraid to dive in. It’s usually pretty simple to get stuck in.
- Users are not stupid. This one is a big one. When users complain about your product, it’s usually not because they’re stupid. Your dad, uncle or whatever that don’t really understand Facebook are not stupid. They just know other shit, and they haven’t learned this stuff yet. And that’s Facebook. They have literally hundreds of user researchers making Facebook simple. When your uncle doesn’t understand your app, it’s probably because it’s pretty unusable. Don’t blame users for that.
- Engineers have professional responsibilities. If you work with software in a company that makes money, chances are you have users. Even if you’re building Spotify, not a pacemaker, you still have a responsibility to your users. They’ve chosen your product, and if it sucks, they’re suffering and it’s your fault. This means that if you’re out chugging beer, the systems you maintain go down, and no one else can pick them up, you get a cab home and fix it. Obviously, don’t let a company take advantage of this responsibility. You should get reasonably compensated. But it’s still a responsibility. You can’t laugh off service disruption.
- Inverting a tree is useful, but not in the way you think it is. I’ve always been a strong believer in academic knowledge, and I loved taking the hardest courses. Particle filtering, non-linear signal processing, abstract algebra, advanced algorithms, etc. If it looked hard I wanted to know it. However, the point of Red-Black trees is not Red-Black trees. The point of graph traversal is not graph traversal. The point is, the tools you have shape how you solve problems. And the deeper the understanding of graphs you have, the easier it will be for you to see that a problem is a graph problem. Just like if you know enough economics, you can see business problems as market problems. And so on.
- Integrating early is always better. This is really mundane compared to all the other grand advice, but if you’re a bunch of people working on a piece of code, avoid branches and avoid submodules as much as possible. It’s really not better to work on your own branch until all is nice and then merge back. Merge early. Merge often. Otherwise you’ll spend a month merging. I promise. Like, I really, really promise … and actually, I guess there is grand life advice here as well. If you and someone you depend on disagree on something fundamental, don’t hold a grudge. Hash it out, as early as possible. Make sure you see eye to eye. The process and the product will be all the better for it.
- Simpler is literally always better. I saw someone write something like “Software engineers spend their first two years building complexity, and the rest of their careers managing it”. This is true. Really true. If you can avoid it, never write a dispatcher. Never write an orchestration framework. Don’t use Java if a bash script will do. Solve the problem you have now, not the problem you might have later. Nothing makes you feel as smart as a well architected, abstract framework for solving really complicated, general problems. Nothing makes you feel as stupid as not understanding how to debug it.
Anyway. This is my list. The nine things I wish I knew nine years ago. It strikes me now that current me would love to see the list Nine Things I Wish I’ll Remember In Nine Years. What stuff have I forgotten that would warp my perspective? I’d love to hear your take on either this, or what I missed on this list.
By: Marcus Frödin from Spotify
https://medium.com/@marcusf/nine-things-i-didn-t-know-nine-years-ago-fcbc757b268b#.9xksp8f8t