I’m a programmer. But I, for some strange reason, often find myself
doing management consulting on different levels. Since my basic
schooling is in programming I sometimes often find myself using
principles that works well for programming in management.
One such principle was something I picked up about 10 years ago and I’m still reaching for that everyday. Here’s my current desktop background, showing that principle to me everyday:
This is a so called truism that nobody says again, but I fail to reach just about all the time. I find it very useful as a guiding north star both in organizations and programming. But what does it really mean?
I have the good fortune to coach some managers in my current position and today we got to talk about that statement above with one of them. She obviously bought into that, as do we all, but I thought I’d try to explain what Simple and Complex mean for me:
To me simple is made up of two components (I think, might add stuff here later): transparency and short feedback loops.
Transparency and trust
Transparent in turn means that the things we do is open and showed to others within our organization and as far as we think it’s reasonable. This is one of the principles we built Aptitud on and we’re pushing the envelope on this. You can see the way we calculate salaries on our website, every invoice is distributed to everyone in the company as are all the pay slips etc. etc.
By having the information as transparent possible (as suitable) people will start to ask questions. Because now they see the information in broad daylight, and they wonder why a number is like that, or they might know that statement to be changed, or they have an idea on how to improve on X.
And
for the record, an intranet will not be sufficient. Put it out in the
hallway! Make it big! I dare you to do an experiment to measure the
different. Create a beautiful page on your intranet with some important
number visualized and pretty. Then try a really ugly, hand drawn diagram
and put it somewhere where everyone pass (close to the reception?). Note
the difference in the number of questions or comments. To the right is
one example from yesterday.
Two very simple things that we have tried lately is:
- make a board with a post-it for every task we’re doing. Do 3 columns (To do, Doing & Done), meet everyday and ask people how every task is going (see below). Only that. Yeah, this is a the embryo to a kanban board. But very simplified. For the current situation I’m helping to improve the communication in the organization. And by using this simple tool it was restarted in minutes. Just by showing people the information.
- Create a hand drawn diagram (like the one above) for some important metric your organization is trying to reach. Put it close to the entrance for the employees. Update it daily. Ask people what they think about that number, or if they want to track another number.
Transparency is not only about visualization of course, although that’s really important for reach. It’s also a mindset to share information rather than keeping it to myself. And if you’re going to share the information people need to feel safe to do so. To me transparency without trust is not really worthwhile. Because people will not be transparent.
If you go “Show me the numbers!”, or “Mr Andersson! Why is the BOR lower today than yesterday?” – people will lie to you. They will tell you the numbers you want to hear. But if you want the truth you will also show the people that even bad news are welcome. Simon Sinek talks about the main task of a manager as being a safe environment. I think I kinda like that.
In my current team we try to solve that but often restating that;
There are no good or bad news. There are just news
I could go on for hours on transparency, but let me just leave you with one more thought; if you’re experience corruption in your organization, what would transparency do for you? What kind of questions would arise? What kind of information would be presented? What will the people involved in the corruption do?
Transparency is a powerful tool. Using it will uncover things. Are you ready to handle that?
Short feedback loops– making it concrete often
The
other part of Simple is to me short feedback loops. For example, when we
create the board with task as above, we meet daily to talk about it.
This has a number of advantages over meeting once a week:
- the information is current
- the meeting feels relevant
- the meeting is short
- problems that will occur (I’m saying anything else) will be small
Funnily enough; if you meet seldom you can go through that list and make the opposites… And you control the dial for that too.
There’s been miles of text written about meeting daily so lets just focus on the last bullet for now. This connects the short feedback loops with the other part of the heading – making things concrete often.
When doing software development nowadays we try to make things concreter earlier by for example:
- writing test cases on how the functionality should work before we write the application. In order to do so we have to think about HOW the system should work without being bogged down with WHAT we need to build to make that happen.
- we run automated tests often. Several times an hours. Because this makes our current progress concrete. “Now that I’ve changed this little calculation, does everything else work?”
- we deploy to production often. Several times a day. Even for big sites like Google (did you see this little feature they deployed without telling anyone for example), Facebook and GitHub. Because if it’s in production it is as concrete as it gets for software: it’s being used, by real users.
Examples in the business world might be:
- post the cash from the cashier to the bank everyday, so that we get a concrete summation for every day.
- track progress towards our project goal daily, so that we don’t go astray for a long time before being noticed about it
- automate the creating of financial statements for the company so that it can be created daily, so that we with little or no effort can create this and have granular progress tracking
Let’s note two things about the lists above but not by doing another list, shall we:
Problems will still occur
But they will be smaller. The longer you wait – the bigger the problem. You control that dial. How much are you willing to pay (to call the meeting, do the reporting, create the automation) to not have big problems, but rather small? This is a business decision. Here’s an example from the world of accounting.
If you post the cash to the bank everyday you get an opportunity to check, that your accounting is correct according the actual cash, once a day. If it’s totally wrong it’s still just a problem that; occurred during the day, firstly, and only during that day secondly. Since it occurred during the day you remember it pretty well (I hope
). Since it only occurred during the day in question the problem cannot be that complex to untangle.
On the other hand: if you post to the bank on a monthly basis, you get the opportunity to verify your accounting against the concrete money once a month. Any problems might have grown big and you will have a hard time remembering what you did up to 30 days back.
Doing the work will take some effort but be faster
Creating this kind of fast moving processes, or creating the possibility to have short iterations is hard work. Sometimes. For example, creating automated tests for your entire system will take a lot of time. Especially if you haven’t written tests from the beginning. Or creating an automated process to create financial statements will not be easy to start.
This is an investment for the organization. An investment to improve and shorten the feedback loop. An investment to give the organization more frequent opportunities to change and react. How much you want to invest in that is up to you.
Ok, that was the Simple part - Complex then, what is that?
Well… it’s basically the opposite of the above:
- the opposite of transparency is hiding information, often in complicated process built in for control, since the information is hidden…. [big breath] often in complicated process built for control of the process, since the information is not open and known in the company. This often creates more complicated processes that’s needed to control… I’ll stop there. Continue for as long as you see it fit.
- the opposite of short feedback loops are long feedback loops and making things concrete seldom. For example, deploying software 3-4 times a year. Making each release risky, hard and complicated. Or creating a financial statement only at the end of each year, spending weeks to do so.
Dude, you lost me… Can you sum it up again?
I’ve
for both programming, life and in management of different sized
organizations followed the principle of Simple = Good, Complex = Bad.
That is I always try to simplify things, even the things I’ve
simplified. I’m never done. I hope.
Simple to me means transparent and doing things in short iterations. Transparent so that as many as possible knows the information and can see it, think about it, question it and suggest new ideas. And feel safe doing so. Short iterations so that we quickly get feedback on our actions, so that we’re rather working with small things quickly than big (or a lot of small) slowly.