Remote Work: Stories of People and Teams Doing Great Things

There are nine and sixty ways of constructing tribal lays,
And every single one of them is right!

Rudyard Kipling, In the Neolithic Age

How many ways can you categorise the ways that different startups organise themselves, the different flavours and colours of organisational culture adopted by companies through their life (and death). Far more than nine and sixty, I assure you. And, yes, each of them is right. Models of the world are usually helpful in making sense of the continuous chaos of reality.

I’d like to propose a very simple and useful model for startup (and, more widely, company) cultures, that I feel is relevant at this point in history: open and closed.

Closed cultures

There are a number of ways to run a closed culture, but the presence of any of the following features is usually a clear sign of an at least partially closed culture:

– Secrecy by default: Business information is closed by default, on a need-to-know basis. Typically, only the senior management team has access to all the information (e.g. salaries and bonuses, detailed financials of the organisation, etc). These multi-layered secrets often form part and parcel of the power structure: the higher you are, the more information you have access to.

– Top-down, hierarchical management: This can be implemented with varying degrees of flexibility, but the common element is the idea that you have a boss and you should do what they tell you. All closed cultures enable some elements of push-back from those savvy enough to know how to make their points from below, but the general mode of functioning is from the top to the bottom.

– The Pyramid/Career Ladder: Closed organisations are without fail mapped out as pyramid-shaped: there is one CEO at the top, with a senior executive team below, and progressively wider layers as you go down. This Pyramid also provides the Career Ladder – the ever-receding MacGuffin that motivates people to work hard so they can one day get on top of the Pyramid and finally achieve true Success.

– Focus on profit: The more advanced closed organisations tend to focus on profit above all. This is measured as a number and is the primary driver of decision-making. If an action results in more profit, it’s worth doing. If the company makes more profit, it is more successful. Profit is the essential driver of all decisions. “How will it affect the bottom line?” is the main (or perhaps even only) question being asked.

– Motivational measurements and individual incentives: Closed organisations, as they mature, learn to apply measurements as a method of ensuring performance. They will measure everything that can be measure and make up targets and projections (with varying degrees of involvement from those being measured), then hold people accountable to those estimates. Those who meet their targets are rewarded, and those who fail are punished.

– Fixed roles and masks: In closed cultures, you are hired for a specific role. You can progress towards more managerial responsibilities through promotion, but typically, doing things outside of your role is discouraged (if only because it will step on the toes of the person who currently owns that role). In closed organisations you are your role. It’s no surprise, then, that most people put on a mask to go to work: while they are at the office, they are no longer a full person with a variety of wants and activities and aspirations, but a “Web Developer” or a “Marketing Manager”. Professional behaviour is all that’s accepted, and it’s all that’s given.

– Distrust and control: A fundamental assumption of closed cultures is that people are lazy and cannot be trusted, so they need to be controlled, otherwise they will not do any work. This gives even more justification to adding more measurements and narrowly defining roles and performance criteria. When they don’t treat them like mindless cogs in a machine, closed cultures tend to treat employees like irresponsible children.

There are countless examples of closed cultures: most of the companies and organisations in the world are run on the closed model. In fact, in many countries it is illegal to run a public company in an open way .  You’ve most likely worked for a closed company at some point in your life. In fact, chances are you’re working in one right now.

Whilst closed cultures (which form the majority of business cultures today) are clearly capable of delivering great results, they have a number of deadly flaws, which I’ll cover in more detail in a later article. For now, let’s look at open cultures.

By: Daniel Tenner from GrantTree

Company culture: an open and shut model

Free the office slaves: No more working day.

The 9-5 working day has come to signify office slavery.

In actual fact though, most knowledge workers work longer than 8 hours a day. A 2011 survey (ASHE) suggests that the average manager in the UK works over 9 hours per day, while extreme hours among certain groups (bankers and lawyers in particular) regularly involved sustained periods of working up to 120 hours a week.

What do set working hours signify?

Extreme hours hurt us. A study by Alexandra Michael, published in 2012, followed investment bankers over a 9 year period. The report concluded that people suffered physical, mental and emotional problems, including depression, a greater number of sick days and relationship breakdown.

Even normal hours often hurt us though. Studies suggest that those in the office spend a large proportion of their time unproductively. They might be checking personal emails or social media sites, or simply carrying out their basic work in a very un-productive fashion. Anyone spent ages staring at a spreadsheet unable to make head or tail of it? Ever fallen asleep in a meeting when supposed to be coming up with ground-breaking new ideas?

The energy cycle

Energy, creativity and brilliance rarely arrive on demand. Instead, human beings work in cycles. We can focus for limited amounts of time. After that we need rest in order to recover.

The ‘ultradian’ pattern, as it is known, normally depends on working in cycles of 90 minutes, with energy troughs in between – normally of about 20-30 minutes. The working day takes no notice of this, however.

Sometimes of course, we enter that wonderful state that Mihaly Csikszentmihalyi referred to as ‘flow’ – where we are hardly aware of the passing of time because we are so absorbed by what we are doing. When we manage to achieve this, the idea of cutting it off with a commute home or a lunch hour seems crazy.

Manage energy, not time

Radical companies understand the need to manage energy, not time. Sometimes that means that workers can work far in excess of the normal working day – developer stories of being so absorbed in a problem they didn’t leave the office until 3am are common. At other times it means workers do far less than the traditional 8 hours and in a different way – starting late, for example, leaving early to pick up children; taking a walk.

No working day means that life and work are more closely blended. It’s not unusual for radical managers to answer emails late at night or to come up with ideas as they sit on a beach with their family. They are not oppressed by this (“oh no! the phone is beeping again!”), partly because they are just as capable of taking a nap when they feel like it or running errands in the middle of what others would call the ‘working day’.

Being Radical

Leo Widrich is a co-founder of Buffer, a company which allows people to manage multiple social media accounts more easily. He manages his own day by splitting it into 90-minute windows and then achieving a certain number of tasks – one per window. A side benefit is that this helps increase focus on just one task at a time, eliminating much of the cost of task-switching. He then tries to plan his rest periods. Instead of allowing these to be filled up with emails or meetings, he goes out for a snack or reads a book. This ensures genuine downtime that allows the brain to recharge and creative ideas to swim up from the subconscious.

So what should we do?

It’s simple really – set people free to work as much as they want, when they want.

There’s no need to say ‘do you mind if I leave early today because blah blah blah’. Just go. It can help to share with others what you’re doing and how to get hold of you so they can co-ordinate with you, but there’s no need to ask permission.

Nor is there any need for that irritating parade of being the last to leave the office, or the first to get there. If someone is emailing late at night it’s because she had a thought and wanted to communicate it, not to demonstrate how dedicated she is.

Some managers might start sweating in light anxiety. How do you know the person won’t bunk off, won’t take advantage, won’t drop their productivity etc.? The answer is that regardless of hours put in people know if someone isn’t pulling their weight or isn’t performing. You can still ask poorly performing people to buck up or get out. But most people want to do well and want the company to do well so they work hard, but you’ve created an environment that helps them work effectively.

You can just trust them.

And just that one piece of advice – trust – frees up a lot of your own time in or out of the working day.

By: Helen Walton from Gamevy

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:

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.
6. 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.
7. 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.
8. 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.
9. 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