Can you build a better culture using product design techniques?
Welcome to this month’s conversation. We’re talking about organisational culture this month and we’re doing it with Isar Bhattacharjee, Head of Organisational Development at IG Group, and founder of Uncover.
Scaling is really hard. We’ve all been at that one company that has scaled too quickly or not paid enough attention to what’s going on inside its walls, and as a result, ways of working become entrenched that might not be ideal for people or overall culture.
But what if we took tried and tested methods from building a product and applied them to how we create culture? Can you really apply the same methods used in product design to people and culture?
Let's find out.
Hello! Who are you and what do you do?
My name is Isar Bhattacharjee, and I’m Head of Organisational Development at IG Group, and founder of Uncover, an organisational psychology company which I kind of started by accident.
That story is that I was consulting for Boston Consulting Group, working with large corporates to help them think about how their teams were set up or how they thought about different strategic people projects, but I wanted to learn more about how others were thinking about the same people problems I was looking at, but from a different perspective.
So I left and got trained as a psychologist with a focus on organisational psychology. During that period a friend who ran a startup called me and asked for help with some people issues she was experiencing. I wanted to explore some research methods that sat somewhere between social psychology and user research - and that's how Uncover was born.
Serendipitous. So what does Uncover do?
We’re taking a break for now due to my new role at IG, but for about two years I worked with a bunch of startups on people issues they were facing. We focused on bringing the latest research techniques and evidence-backed interventions from the research work to the business world.
Can you tell us more about the people issues you often see?
Sure, so we’ll start at the beginning. Back in the 80s through to the early 2000s, people functions were human resource functions. They largely focused on HR operational decisions and process-related things that were really crucial, like payroll, contracts and maybe some L&D if you were lucky.
But the problem with that is that while those things are essential to how a business runs, they do kind of treat humans as resources – as the name HR suggests! But then, in the late 2000s, maybe 2010 onwards, everyone was suddenly building software and the big war for highly skilled people, like great developers, great product people, great designers and so on, began.
And that competition meant you couldn't necessarily just think of people functions as operations functions anymore; there had to be a way of attracting the best talent and then, to some degree, developing that talent.
But the way that that manifested was often in things like benefits, which can be great, but not necessarily super impactful on how people work day-to-day. It included things like pizza in the office, or Friday bars, or breakfast and all these things. They're nice, but they're essentially a form of bribery to get people through the door.
What makes you really happy at work isn't croissants in the morning, it’s when you're being really effective.
While it was a good start to rebalancing that leverage of power from the employer a bit to the employee, these people functions tended not to be super thoughtful about how people actually did their jobs.
But I think we're now going through a third wave and in this third wave, we're thinking much more holistically about what makes you really happy at work.
And that’s not croissants in the morning, it’s when you're being really effective; when you're not annoyed by processes that don't work; and when you're not frustrated by things being a massive waste of effort. You want to be learning and to be constantly feeling like you are growing and changing and being challenged, all while being supported.
Intrinsic motivation over extrinsic?
Exactly. There’s a great paper by Deci and Ryan who wrote about self-determination theory. They say three things drive intrinsic motivation; autonomy, which is control over your life; mastery, the ability to get better and improve; and relatedness, which is a sense of connection, both to the work you’re doing but also to the users you solve and the people you’re working with.
Modern people functions should do everything they can to get better at all three of these, no matter what it takes.
And that means that the boundary between organisational and people interventions is becoming increasingly blurred. Having a goal-setting process and OKR process should be the responsibility of people functions because having your people focus on the stuff that really matters is key to them having an interesting and fulfilling job.
Do you think this third wave was always coming?
Yes. We’re asking companies to deliver more with less, because technology is getting better, and the ways of working are changing. COVID was a massive accelerant in forcing us to rethink how we operated, which was great. Not only can we now have this virtual conversation, no matter where we are, but it also forced us to see that we could change how we operate and how we work.
Even just that mental reset of, OK, we had to do this absolutely horrendous thing where everyone was locked inside, but we managed to make it work. We managed to make it work because those constraints were clear and we coloured within those lines as creatively as we could.
It's often the constraints we don't even realise are constraints that are the ones that most drive behaviour.
I know comundo has a four-day week and that to me is a really interesting constraint because it's like, okay, if we've got four days, you just have to get whatever you're gonna get done in those four days. And that pushes people to work differently and think differently about their time and about what's important.
Post-COVID I think we’re much more used to that feeling that we can change the way we work, and I think there’s an opportunity in that; companies should be doing more almost forced reset moments, where they really think about how they’re working.
It's often the constraints we don't even realise are constraints that are the ones that most drive behaviour – you know the old adage about fish not realising they’re in the water – and I think there's so much of how we work that is like that water. For example, if you’re going into an office and then spending seven hours of that day on back-to-back virtual calls, why are you even going into that office?
Another good example was when I was working with a company that had a relatively siloed way of working, so one function wasn’t really talking to the other, and even though they weren't a massive company, about 140-150 people, they still struggled with silos. It's amazing how few people you need for one bit of the org to not know another bit of the org is doing, especially at an early stage; the more ambitious your company is the more people are just running with stuff and that stuff is changing very quickly so it's hard to keep up.
So, we tried a bunch of things that other companies do, like a newsletter, a town hall meeting and so on, but for some reason, it wasn't working. So we looked at their physical office in London, and what we saw was that all of them sit in little functional clusters and as a result didn’t know very much about other functions.
We started wondering if they’re doing that because that’s how they’ve always done it, or if it’s because that’s what they need to do their job. So – after asking for consent – we set up cameras in the room and we watched. Turns out, something like 90% of your interactions are with the people who are directly next to you, which was kind of expected.
But the question is: Are they talking to you because they're next to you, or are they sitting next to you because they need to talk to you? So we shuffled up their seats so the functional clusters were no longer clusters – instead, everyone was mixed up. It turns out around 70% of interactions were still with the people next to you – even if they had nothing to do with your job.
As a result, what each person knew about different functions changed radically. If you’re sat next to the product person, you’re going to have a pretty good idea of what kind of product they’re working on – even if you’re not deliberately talking about that, which was interesting.
It’s another example of how we’re still learning post-COVID what works and what doesn’t.
You mentioned silos and ambition and early-stage companies. Are there common issues startups and scaleups face?
Yes, absolutely. They often run into what’s called ‘organisational debt’ or ‘people debt’. The first person to address this was Steve Blank, back in 2015, I think, but the concept wasn’t really discussed all that much, despite it making a lot of sense.
Debt is the ideal word for it because there are several characteristics of how people run companies that are similar to how we think about either monetary debt or technical debt. For example, when you're growing quickly as an organisation, you have to make lots and lots of decisions. For some of those decisions, there's an easy route that is effective and gets you a good answer quickly, and for others, there's a tough route that takes you more time and effort upfront.
It's totally rational to take that quick and easy path, especially when you're growing, but you’re borrowing against future effort; hence the word ‘debt’ – at some point, you’ll have to pay it back by tidying up the mess that comes with quick and easy solutions.
On top of that, all these short and hacky solutions can eventually start to slow an organisation down. All those quick fixes eventually accrue an interest that starts to pile up and impact present efforts. It’s a bit like an overdraft at a bank; you can tolerate it for a while, but as it grows, it can have a very significant negative perception impact.
Do you think this kind of debt can be avoided in startups?
No, I think it’s rational. In fact, you shouldn't try to avoid it because if you're avoiding it, you're building a bunch of things that are much clunkier than you need too soon and it's a massive waste of time and effort.
The number one problem I consistently found in startups was that they were doing too much stuff and doing that stuff not well enough. If I could give all startups one bit of advice, I'd tell them to do half as many things and do them twice as well.
If I could give all startups one bit of advice, I'd tell them to do half as many things and do them twice as well.
There are always a few traps that you need to be wary of in startups and scaleups. Trap number one is that if you always wait for stuff to break before fixing it up, you're going to appear very reactive and people in your organisation are going to feel like the way you’re setting things up doesn’t make sense, which means they're going to be frustrated. Also, frankly, it means you will have lots and lots of frequent changes.
A good example here would be, say one part of the organisation is not working particularly effectively, and you try to fix that one bit by restructuring the team but then in three months there's a bunch of other problems in the same part. But if you spent a bit more time doing discovery work, you could have probably found out the real reasons three to six months ago and fixed the issue. It could be a very boring problem, like their tooling isn't working or that their process isn't particularly efficient, but because that’s not what was fixed, other issues keep surfacing, and that same team feels like they're going through like round after round after round of change. That can be very unsettling to them.
Another trap is where stuff is not bad enough to actually break but it's just getting slightly worse collectively. That can really slow down teams. A really good example of this is meeting culture.
So, if I’m going to do a project with you, we'll set up a meeting once a week. At the start when we're really busy, we need to meet once a week and then three months down the line we probably don't, but the meeting stays in the diary. And then, four or six months from now, we might not even remember what the meeting's for, but it’s in the calendar so we go to it. And maybe it’s not just us. Maybe it’s four or five people! And if you multiply that by 10 projects, suddenly the amount of time across the organisation you're losing is quite high – not to mention the cost.
Another example of stuff not breaking but slowing things down is decision-making culture.
Another example of stuff not breaking but slowing things down is decision-making culture. Often, when you're very small, you can basically have most decisions go through your leadership group, and then, as you get bigger, there's almost a clear point in time that starts to be a massive bottleneck. And then, eventually, it goes from being a bottleneck to being actively disempowering for teams.
In an ideal world, you should be changing your decision-making process as you grow, so that it matches what your organisation needs, but the reality is that senior leaders often don't have the mental space to even think about how they're making decisions. They often don't know how that process is impacting others in that work.
What you need are these clear reset moments, where you say, okay, we’re a year into it, let's think about what’s working and if it still makes sense. Or, we've just hit a head count of 75 people. That's different to when we had 20 people, so does the stuff we were doing with 20 people still make sense now we’re 75?
How can a startup that's starting to scale make sure it doesn’t fall into these traps?
Regular periods of discovery are really helpful. So, a good example of this is a company I know where once a year, the founder goes through the onboarding process that all new employees go through.
Having a CEO or founder in the process can significantly change its tone and content; Why are we spending six hours on expenses? Is that really what these new hires need to know? Surely our strategy, team setup or how we operate is more important than expenses!
I like the idea of treating onboarding like an internal product.
The CEO in the onboarding example is doing exactly the kind of dogfooding we expect people to do in customer-facing products but almost never do internally. There’s a lot we can steal from product design and incorporate into the people side of an organisation.
Companies don't measure their internal projects and processes as much as they measure their external ones. But they should be and could be.
Companies don't measure their internal projects and processes as much as they measure their external ones. They’ll do loads of A/B testing on their product, they’re super data-driven and know exactly where in the funnel people are dropping off, but they're usually not as data-driven when it comes to how people are feeling about work, what's driving retention and what’s a good exit versus a bad exit. But they should be and could be.
It’s funny because if you were a designer or a product person, you would want to sit with your users so you can learn everything about them and how they’re using your product. But when we look at internal-facing roles, like HR, we typically don't ask them to do the same.
Your product has lots of different features in it, some work well and some don't, and you have users who care deeply about the product and are served by it. As an internal people person, I should be doing the discovery about what works in my organisation and what doesn’t and what my “users” think about the “product”.
I really think we can take lessons from how we build a product, i.e. user discovery, incremental shipping of features, gathering feedback, and apply those practices to how we work as an organisation. Internal processes are then user-led and built around the very people that make our product and – create our culture.
There are a lot of lessons in this and it was one of those conversations (aren’t they all) that could have gone on for much longer than the time we had allotted. Hopefully, we’ll catch up with Isar at some point in the future – and remember regular periods of discovery.
Come to think of it, we might be overdue one already …