Some management consultants claim that you can’t change an organisation’s culture.
This is nonsense.
Numerous other management and change consultants claim they can change an organisation’s culture.
This too is nonsense.
You can change your organisation’s culture … from the inside.
Indeed, a leader’s responsibility includes Shaping their Organisation’s Culture.
I am going to share two successful stories of leaders driving change in their companies. On both occasions, I was engaged as an external consultant with the brief to co-design and facilitate the process and selected interventions.
Engineering Inc.
From a loss-making conflict-ridden environment where indifference and lack of trust reigned, to a profitable integrated company with engaged employees. The company is now a unit in a global corporation and a Centre of Competence for its product line.
The Situation: A new CEO had recently been appointed to a company which had changed owners 3 times and been making losses for 8 years. The environment was poisonous: chaotic production processes, cynical, continuous conflict with customers due to delivery and quality issues, abuse of the system by middle managers who themselves were not trusted by the production engineers and technicians. Closure was a possibility with 300 jobs at risk.
Changes and Process: Three new engineers were brought in to fill critical positions: Chief Engineer, Senior Project Manager, Site Manager. We conducted individual interviews with all managers, held focus groups at all levels, engaged the works council. Product demand fortunately was not an issue. Customer relations unfortunately were a serious problem. The CEO appealed for support. He laid out a clear strategy with a message of the environment and changes needed to continue operating. Changing the focus from inward (protectionist silos) to outward (the whole business with customer needs as focus) we used strength-based approaches to realign around real business Questions, whereby employees were invited to contribute. The production and logistics process was changed completely; skills deficits were alleviated; product design now involved production; the management team began to work as an integrated unit; employees wanted to contribute to improvements. Three middle managers who resisted the changes were forced to leave. Additional jobs were created in production as demand rose. Within two years, the site was making a profit.
Key Change Success Factors: The need: without change, the company was in serious danger of closing. Leadership: A driven leader who everybody trusted – he was visible, approachable and walked the talk. His messages were clear and he listened. Involvement: People learned not only that their contributions were desired, they experienced that the invitations they received were genuine.
Finance Inc.
From a small sleepy company in which employees had a lackadaisical approach to their work and customers, to a dynamic market leader whose customers praised service quality.
The Situation: A small specialist data processing company was acquired by a global corporation. A new CEO was installed together with two experts from the parent company. The environment was friendly and relaxed. There was little engagement, people worked with an eye on the clock, problems were referred to management, error rates were high, clients were irritated.
Changes and Process: The new CEO laid out clear guidelines, expectations and his vision of potential opportunities. All employees were invited to play an active role in working groups that defined and implemented new more efficient practices and new customer interface processes. Customer orientation was prioritised. The two new specialists were appointed to lead functional units, otherwise, the only hierarchy was towards the CEO. Processes were defined, personal and team responsibility was expected, engagement levels improved significantly, the environment was noticeably more dynamic, problems were solved at the level at which they occurred, customer satisfaction indices increased dramatically. Within two years, the number of employees increased three-fold as new clients came on board.
Key Change Success Factors: Leadership, Trust and Recognition: Clear consistent Leadership; clear guidelines; employees felt valued and freer. Involvement: employees were able to see the impact of their contributions.
Culture is the continuously evolving dynamic interaction of the mindsets and gutsets of all the actors in the system. It is the Soul of the Organisation that drives the behaviours we observe.
In many if not the majority of organisations, observed behaviours reflect not the values of the people within the organisation, but those hidden values of the organisation as a system, frequently driven by inappropriate leadership. By inviting and encouraging the people to engage with the system, leaders can lead a change from a negative to generative culture. Indeed, this is their responsibility.
And in the fast changing world of the early 21st century, shaping an adaptable organisational culture is becoming a survival essential.
Yes … You Can … Change Your Organisation’s Culture!
By: Eric Lynn from CultureQs
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
How the Future of Tech Impacts Work Habits
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.
Your Engineering Team Is Not an Island: Success Demands a Holistic View of the Business
I just re-read the awesome post from my friends David Loftesness and Raffi Krikorian, What Does A VP of Engineering Do Again? And while I agree with everything that they say, I think there is one crucial item missing, which has been present in every job I’ve had because all of them were user-facing internet services and a majority of my job has been working with product teams. Collaboration with stakeholders (especially with product) is key, but if you take it one step further, a VP of Engineering is actually measured by execution in a wider context across many teams or departments. You cannot look at engineering in isolation for your successes or failures.
But first a short story about my first months at SoundCloud. The CTO wanted more front-end work done because an important release was nearing. He asked me to hire more engineers to accomplish that goal. I started recruiting, but then I looked at why the velocity of the existing team was not meeting expectations. So, I went to all of the front-end teams (at that time it was Web, iPhone, and Android) and asked a very simple question “What slows you down the most in your day-to-day work?” To my surprise, everyone gave the same answer “We only have one designer.” They went on to say that although the designer was very good, she was completely overloaded so designs, changes, and simple clarifications took forever to get done.
Now that I knew design was actually the cause for delays, the solution to my problem was not to hire more engineers (which might have even made the problem worse with more work for the designer), but to start building a design team.
Engineering leads need to look at the whole product process (together with the responsible stakeholders) and not just at engineering in isolation. What I did was a very simple (but, in this case, effective) form of value stream mapping. Our self-improvement at SoundCloud continued. You can read Phil Calcado’s excellent post about the organizational aspects of microservices at SoundCloud.
The Best Engineering Leads Will Stop and Assess the Situation
Continually assessing situations in a holistic way isn’t just the job of an engineering lead — everybody involved should take responsibility. But, in my experience, the problem usually surfaces in engineering because when things are not moving fast enough (and when do they ever?) management’s first reaction can be to throw more engineers at the problem so more work will get done, but also (and this is the not so nice scenario), management thinks the engineers are not working hard enough. Other common responses from management include reorganizing the teams or adopting new methodologies. However, as an engineering leader, you are a lot like a doctor: you need to diagnose the illness before treating the symptoms.
Engineering leaders need to look at the whole value chain and to sit with the leaders from affected departments to review at the problem. The solution to a problem might not be to hire more people (which a lot of startups do), but to organize product development in a better way. And if you have to hire, it might mean that you have to move headcount around. When everyone has the same goal goal — delivering more business value — shifting headcount from engineering to design or to recruiting shouldn’t be an issue. Afterall, the goal is more business value, not having the biggest department. So, when I realized our problem at SoundCloud wasn’t going to be fixed by adding more engineers, we created a design team. But this was just the first step towards a better setup.
Even after creating a larger design team, it remained isolated from other departments and was not fully integrated with our workflows. The problems of turnaround and wasted resources were exacerbated by the increasing risk of misalignment between product, design, and engineering. Therefore, the next logical step was to improve the organization by creating a delivery team per product.
Shifting Organizational Structures to Deliver Business Value
A delivery team is a team that can deliver the vast majority (95%) of its backlog items to production without dependencies on other teams. Unlike more horizontally-oriented teams (for example, a front-end engineering team that relies on the back-end engineering team for any back-end changes), a delivery team has all the necessary skills inside their team. So, depending on your company and your product, these teams can look very different. In engineering teams that are infrastructure focused, these teams can consist of only engineers; but if you look at a team that delivers a consumer-facing web app, then the team looks more like this:
Creating these delivery teams and then making sure you have the right staffing for them should eliminate a staffing mismatch between the affected departments. Some team members (like support) might just be a pointperson for the team, e.g., the support person only attends the daily standup and reports what is going on.
So, don’t look at engineering in isolation when trying to solve delivery problems. It is critical that each engineering leader (and especially the VP of Engineering, who can really influence the organizational setup) ensures that the overall product development process is set up in a way that reduces waste and delivers value to the customer which is the whole point of product development in the first place!
This post includes material from the upcoming book “Scaling Teams” by myself and David Loftesness, which will be published by O’Reilly in 2016. In this book, we will explain in detail the various scaling challenges of software startups.
Thanks to Laurel Ruma and David Loftessness
By: Alexander Grosse from issuu