Nine things I didn’t know nine years ago

May 19, 2016 by lsmit@wemanity.com in Blog

Image from page 400 of “The Palm of Alpha Tau Omega” (1880)

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

Why we should lean into risk in Brexit Britain

May 10, 2016

I was going to write a blog about risk. I’d whip through the theory, focus on the practice, and back it up with science.

Then the referendum happened. And now, depending on your view, the country’s either deep in the mire, or free to succeed. The markets have crashed, but might bounce back. Hate crime is up, but might be a blip. We’re living in uncertainty, and we don’t even know how long it’ll last.

All of that feels uncomfortable and risky. So to write about risk without acknowledging the uncertainty around us feels a bit absurd. We’re already awash with political analysis, so I won’t add mine. But whether you’re delighted, devastated or unmoved by these events, it’s an interesting moment to take a look at the parallels with organisational and personal change.

Major change throws the status quo in the air. Before it settles, as it inevitably will, we can make some choices. We can pretend it’s not happening. We can choose to step back and see where the pieces fall. And we can choose to take a risk and lean into uncertainty. These are decisions organisations are making now – as they’ve done before and will again. Individuals are doing the same.

Unless you’re very lucky, pretending nothing’s changed will leave you baffled, and your colleagues disengaged. It’s also, counter-intuitively, a lot of effort. Our ability to adapt is part of what defines us as human. So while adapting might be hard, refusing to is exhausting. Sometimes, of course, the wisest move is to hold your horses and wait for a new normal. But you forfeit the chance to shape it, and risk being left behind.

Choosing to shake hands with uncertainty can be complicated and uncomfortable. It can also be profoundly creative. If you can lean into that, there’s scope to experiment with new ideas and products, have different conversations and make unexpected connections. You might fail, you might succeed, you might create something a bit… ‘meh’. But you only find out if you take the risk. And whether or not it’s sparked by external events, embedding a culture of testing, adapting and improving will reap benefits well into the future.

Thing is, it’s not easy. There’s a gap between intention and doing. And however much you want to, crossing it can seem boring, painful and hard work. And once you do cross it, there’s no guarantee it’ll work. Ugh. Why bother? It’s somehow easier to feel disrespected afterwards than to challenge in the moment. To feed back to your friends instead of your colleagues. To work within stasis than to venture an alternative.

But that ‘ugh’ is worth the bother. It’s when things shift, and when you learn. Plus you reinforce in yourself and colleagues that, whatever the outcome, you are people with the agency to create change. You’ll be more likely to do it again, helping build a culture of creativity in yourself and others.

So where to begin? Here are three initial suggestions.

1. Acknowledge fears, but don’t draw them out. Give yourself three minutes to project the potential range of outcomes from best to worst. Then begin, ditch or adapt. You’ll only find out what actually happens by taking the risk, so don’t waste time on the fundamentally unsound, or delay the great.

2. Solicit feedback; ask, listen, learn, adapt. And be specific: work out exactly what you want feedback on, and ask questions within a clear remit. This shifts the focus away from egos (easily crushed, despite denials) and towards ideas. Seeking feedback can feel like a massive risk in itself. But the more you do it, the easier and more useful it becomes.

3. Build networks. It’s exhausting taking a risk on your own and it takes ages. Talk to people who disagree: diverse opinion makes for robust ideas. And test the idea as soon as you can, drawing on your network for support. Make sure your network includes people unconnected to your idea, but who can help you reflect on progress and remain resilient. Action learning sets and peer mentors are ideal.

I’m not suggesting all ideas are sensible or risks worth taking. But change is definitely coming. New systems, new products and even new industries may emerge. I hope that as organisations and individuals we’ll be inspired to lean into risk when we encounter it. Start experimenting, adapting, innovating. The status quo has been shaken, and will rebuild. The space in between is yours to shape.

By: Kamala Katbamna from Chirp

http://www.chirp.org.uk/new-blog/2016/6/29/risk-taking-in-a-post-brexit-britain

Company culture: an open and shut model

May 20, 2016

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.

hierarchical-pyramid

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.

Open cultures

If there are many ways to run a closed culture, there are even more ways to run an open one. Each open company tends to have its own way of expressing its culture. However, these are some typical commonalities by which to recognise an open culture:

– Transparency by default: In open cultures, business information is publicly available to all employees. This includes salaries, but also bad news, strategic plans, problems, decisions, ideas, etc. People are trusted to be able to handle that information.

– Flat hierarchy and/or self-management: If everyone knows everything and you’ve hired smart people in the right kinds of jobs, it is very difficult to maintain an arbitrary hierarchy, since everyone can contribute to any decision. When you trust people, it is also unnecessary to set up managers whose job it is to check after them.

– Personal development through work: When there is no career ladder, how do people achieve career progression? The obvious solution is that they take on more responsibilities without having to go “up” an arbitrary ladder. As a natural consequence of that, it is possible for people to fully express themselves in their work, by getting involved in their full range of interests, so they can achieve more personal development than they would in a narrow role with a career ladder.

– Multiple stakeholders, values, and purpose: In open organisations, the idea of valuing profit above all others becomes obviously absurd. It’s not only shareholders, but also employees, suppliers, customers, society, and the environment, which matter. The company does not exist in a vacuum. Values become a way to express what the company cares about, rather just a motivational slogan. Along with the higher purpose of the company, they become the way that decisions get made in open cultures.

– Team or company incentives: There is a progression from the closed culture approach of individual incentives, via team incentives, towards the eventual ideal, which is a system where base pay is determined by a combination of what the person is contributing, what the person needs, and what the company can afford, along with company-wide bonuses. Individual incentives are shunned.

– Self-determined pay: One of the surefire signs of an open culture is when people determine their own pay. In most companies, this is unthinkable. In open cultures, it becomes a natural consequence of all the other stuff. After all, if you trust people to make all sorts of important decisions about the company, why not trust them to make this decision too?

– Separation of role and person: The idea that a person and their role are intrinsically bound becomes visibly stupid as the culture opens up. Eventually, it is clear that people are not their roles, but are capable of engaging in several roles simultaneously, contributing more fully to the organisation’s needs. This further enables people to accomplish themselves and to be fully themselves at work instead of wearing masks. One of the ways this is accomplished is through Open Allocation.

– Trust: Perhaps most important is the fact that open cultures treat employees like adults, trusting them to do the right thing even in complex or ambiguous situations. There are of course processes to help people make better decisions, but the key point is that all these processes start from a perspective of trust and responsibility.

The benefits of running companies this way ought to be obvious, but in case they need to be spelled out:

– People in open cultures are more engaged, happier, more creative, they contribute more, etc. This makes them much more fun to work in, both as a founder and as an employee, but also much more productive – people work much more effectively when they care.

– Having a better environment makes it easier to hire great people.

– Open cultures are way more adaptable to change. Change management is an oxymoron in an open culture: change happens constantly and continually, not through expensive, long-winded, and often failure-prone change processes.

– Because they motivate people so much better, open cultures are, ironically, also better at achieving sustainable, long-term financial results.

There are some examples of open cultures out there, too, to varying degrees.GrantTree, Buffer, Valve and Github, in the startup space, are known examples of open cultures. Others include Semco, Burtzorg, Happy Startup, MorningStar, and many others in all sorts of different contexts and sizes. All companies could adopt an open culture, but most don’t. Why is that?

Reinventing Organisations, by Frederic Laloux, studies a dozen or so open cultures and comes to the conclusion that two things are absolutely prerequisite for an open culture to exist for any length of time: both the CEO/Leader and the owners must be fully supportive of this (currently) unconventional way of operating. Otherwise, eventually the company hits a hard time, and either the CEO or the owners pressure it into returning to a more traditional (i.e. closed) mode of functioning. So the obvious reason why more companies are not currently open is because most CEOs are not prepared to let go of their control mindset, and when they are, the owners (whether private owners or VCs with board seats and a traditional, closed mindset, or simply public markets) frequently won’t let them.

If you’re a founder of a startup, this poses an interesting challenge: are you up to the challenge of creating an open culture in your business? Even when that involves giving up the trappings of power? Even when that involves passing on an investment round from an investor whom you know will force the company to change its ways when it hits a rough patch?

If so, welcome to the club. Follow this blog, and I’ll do my best to share what I’ve learned in transforming GrantTree to be an open company. This is still a new field so we can all learn from each other.

By: Daniel Tenner from GrantTree

Company culture: an open and shut model

What Rugby Can Teach You about Trust in Agile Teams

May 26, 2016

Summary:

Unconditional support, trust, respect, generosity, and courage are the behavioural values required for agile—and also for rugby. On the surface, the software development methodology and the rough team sport may seem to have little in common. But Luis Novella writes that rugby can actually teach you a lot about agile.

When I recently joined an agile team, I suddenly realised I had actually been implementing agile for a few years, just without leveraging the branding. It wasn’t until I listened to Johanna Rothman speak that it dawned on me: Not all things called agile are truly agile, and there are a lot of practices that are agile but are not categorised as such.

Once I understood what agile really means, I realised that I’d seen many of its central tenets contained in another system that’s important to me. Unconditional support, trust, respect, generosity, and courage are the behavioural values required for agile—and also for rugby. On the surface, the software development methodology and the rough team sport may seem to have little in common, but in this article, I’ll show you that agile and the sport of rugby are alike where it really counts—and understanding how to be a team player can improve your career as well as your game.

Trust in Your Teammates

Rugby teaches you to find the most optimal, collectively intelligent strategy within a group of diverse and versatile individuals. When everyone has this mindset, you get sustainability, innovation, and the pleasure of working with a team fully engaged toward a common goal. Overall, rugby is a decision-making game that focuses on shared leadership, and many types of it. It assumes that individuals will be specialists for certain tasks, but they will have the contextual intelligence to make the best decisions for the team based on a deep sense of self-awareness and consciousness of the other team members and the progression toward the goal. Sound familiar?

Despite having played a few rugby games here and there when I was younger, I never imagined the endurance of the behavioral blueprint the sport could generate in a high-performance team. I would argue that the training provided by rugby in terms of behavior is useful regardless of what agile technique or method best fits the particular challenge.

One of the key elements is trust and unconditional support between team members. Despite 160 years of updates, improvements, and new laws, rugby teams at any level still function the same way: When the player with the ball makes a decision, every single teammate actively supports and engages with his position and the context, aiming to provide the best options for the ball carrier (who is always the boss in rugby, if you are into the boss concept). Every player trusts that the decision-maker will make the best choice based on his vantage point, opposition, position on the field, and available support. Once a decision is made, everyone on the team makes the maximum effort for the result of that decision to accomplish the best outcome for the team.

The decision-maker also trusts that everyone behind him will be attentive and available. He believes that if his execution fails, no one will recriminate him; instead, he will be supported. In rugby, you inevitably “fail fast” and make plenty of decisions that turn out to be negative, but you know your innovation was encouraged and respected by the team. Your team trusts that you did the very best you can. They also trust that you have trained and prepared yourself to have been in the best possible condition to play.

Trust releases many opportunities in life. You can innovate and create. You can surprise the opposition. You can discover abilities in your teammates that you did not know were present.

I have had the advantage of working with business leaders who have the courage required to embark in agile transformations the right way—to really and truly happen, change has to start at the top, and the first one to change has to be the inspiration leader. In my opinion, this trust and ability to innovate and err generates pleasure in what we do. It makes our work open and helps us measure and get feedback, because you also trust that the people around you want to make you better.

Just like rugby, agile is a learning system in constant change played by a collectively intelligent team, and the team’s every move is enabled by trust.

By: Luis Novella from the Spark Team

https://www.agileconnection.com/article/what-rugby-can-teach-you-about-trust-agile-teams?page=0%2C1