Stephan is a CTO coach. He has been a coder since the early 80s, has founded several startups and worked in small and large companies as CTO. After he sold his latest startup he took up CTO coaching. He can be found on LinkedIn.
When I was joining a startup with plans to replace the CTO, there was a relaunch going on. I’ve talked to people and no one seemed happy. Developers were unhappy and helpless and the founders were also unhappy with the relaunch. I’ve heard it had being going on since months. The whole company couldn’t understand why tech didn’t deliver. Digging deeper I found over 150 open bugs in a small team, a founder who changed the design every week and a product manager sandwiched between the unhappy founder and the unhappy developers. I forced the founder to make a lasting decision, we fixed or closed all of the bugs and delivered a new website. The founder team, developers and I were happy, not to speak of the product manager.
Developers are trapped in a cycle of bad decision making in startups. Companies are bad at making decisions. Founders and executives treat decisions as a way to show leadership, the woman or man at the helm being able to decide about the future of the company. Creative visionaries come up with new ideas and decisions to build new products every day, changing direction on a whim in the chase for customers and investor satisfaction. Developers bear the brunt. They believe a process around decisions in startups and companies is not of their concern. They only need to execute. Tell me what I should code.
I hear from founders and CEOs who want to speed up development because they have the perception technology is slow. With the abundance of knowledge on processes, lean development and of-the-shelf technology this is unlikely. The perception of development being slow is the impact of a bad decision process in startups. For development the negative consequences are time pressure, constantly changing requirements, ongoing reprioritizations and therefor even more pressure and blame.
We will investigate why decision making is broken, what consequences this has for developers and CTOs and how to fix it.
0.
“Our research shows that the difference between leaders who make good decisions and those who make bad ones is striking. The former recognize that all decisions are processes, and they explicitly design and manage them as such.”
David A. Garvin and Michael A. Roberto in HBR
To many people decision making is an event, while decision making is a process. This perception causes several bad side effects. The most important one is that their decision has not the intended effects. Founders wonder why after taking a decision, the company does not change. Why after taking a decision they get a lot of discussion instead of people executing their decision towards success.
How does one change this? How would a decision process look if done right?
The four steps of a decision process are:
- Prepare
- Make
- Rollout
- Enforce
Let us look into each phase in more detail. I’ll show how mistakes in all four phases have impact on software developers and CTOs.
Image for post
Image for post
The four stages of a decision process
1.
The first phase is ‘prepare a decision’. Preparing a decision means getting the facts and information that are needed to make a decision. It also means getting feedback and the mood from stakeholders about the decision. If you surprise people with a decision, you have done it wrong. If as a founder you want to make a decision, ask your management team before what they think about it. First in a team meeting and then in one-on-one discussions with your managers. Get the buy-in from everyone that a decision needs to be made. Make sure everyone knows if the decision is to be a team decision or something a founder or managers decides.
Without the right preparation, managers make wrong assumptions, miss key parts of the decisions or do not think about consequences. Bad preparation leads to features in development that take too long, are too complicated, hard to maintain or not worth the effort. If a decision has large infrastructure impacts, feature implementation will take a long time. Cost and time pressure is put on the CTO because of badly prepared decisions.
2.
The second phase is ‘making the decision’. When you have the buy-in from everyone and all the information you need, it is time to decide. Decisions with consequences are hard to make with all the options on the table. For this managers postpone decisions to not lose options and commit themselves. If you have all the information and you have the feedback from people, make the decision and do not delay it. Break the pattern to move the decision to next week’s management meeting because of the desire to not constrain yourself. Make the decision as fast and as early as possible despite the fear of making the wrong one. A mistake I often see around making decisions: it is unclear on how decisions are made and who makes them. Introducing a decision framework like RACI helps here. It defines roles people have:
R = Responsible: The person or people to successfully execute the decision
A = Accountable: The person or people who make the decision
C = Consulted: People who are asked for input to the decision
I = Informed: People informed about the decision
This way roles are clear, and it is clear who makes a decision e.g. the CEO, CTO, Head of Product or the group. Otherwise people often confuse their role of giving input and with making a decision.
Not making a decision has bad consequences for development and CTOs. All the time lost prolonging the decision is put on development as pressure to speed up development. Donald G. Reinertsen shows in “Developing Products in Half the Time” that half of the time to market is lost in the “fuzzy frontend” before development even starts. If I consult a company, I tell people it is hard to cut 10% out of development time with already agile and lean development departments, but it is easy to cut 50% out of pre-development time. Every second after an idea is found in a company is as precious as a second in the last week before launch. People treat these differently though. Time in the decision making phase is treated as an unlimited resource and time in crunch mode before release is treated as gold. The most urgent job for a CTO is to have a decision process in place and force fast decisions to make his life happier. It helps to write down the dates of when an idea is new and when development starts to optimize lead times.
3.
While some people are at least able to make timely decisions, they fail miserably at rolling them out. Decisions are made, decisions are communicated by email or in all-hands meetings and decision makers expect the course of the company to change. They do not understand that after making a decision the most important next step is rolling it out. Every important decision involves change management. Rolling out a decision means communicating the decision, explain the decision, explain why alternatives have not been chosen, explain what the decision means for the company, departments and employees. Transparency about the decision, the reasons that the decision was made the way it went is paramount to success. Every decision needs to be explained in one-on-ones to make it stick, let people vent their feelings, get feedback and the buy-in from those carrying it out. Proclaiming you have decided something will not make the decision stick and will result in a disaster. The company ignores your decision and just carries on. Founders feel frustrated and react with pressure on execution.
When not rolling out a decision and explaining the circumstances, people have different perceptions about it, how to interpret it, what it means for them, the state of the company, what is important and what to focus on. This creates increased friction all over the company. As development needs to work with many parts of the company, it is highly impacted by high friction and differing assumptions and perceptions. If a company has a decision process with good rollout practices friction is minimized and development speed is increased. High friction leads to low development speed which is blamed on developers and CTOs.
4.
The last phase of decision making is enforcement. There are many people who will not be happy with your decision.
“Surely a decision is a decision?” “Only if it’s the decision you want. If not, it’s just a temporary setback.” Sir Humphery, Yes Minister.
They will ignore it or try to reopen it. There are many ways to do so. Managers will sabotage decisions if they don’t like them and you don’t act. They agree with the decision but do not carry it out. After a decision has been made in a meeting, next week people will claim “This is not the way how I have perceived this. We haven’t made a clear decision.” People act just as if you haven’t made a decision at all.
After making a decision and rolled it out, it’s time to enforce it. Every decision has to be recorded in meeting notes or in other forms to make it clear to everyone that a decision has been made, how the decision looks and misunderstandings are reduced. Without writing it down people will leave a meeting and everyone has a different understanding and takeaway. If people show tendencies to counteract your decision, bring them back on the right path. Explain the decision again. Then explain it even more. Remind people of the decision. Pull out the meeting notes. There will be opposition from many people who had a different opinion. After you’ve made every effort to convince them and take them with you, it’s the managers and founders duty to enforce the decision.
Because the effects of a decision often cannot be seen immediately, people reopen decisions too early. If there is no new important information, don’t reopen decisions. Stick to them until you clearly see you have to change them. Change decisions as soon as needed but not earlier. Flip flopping decisions creates confusion and frustration.
Changing a decision is easy and involves not a lot of work. But the more your work is down the execution chain, the bigger the impact. A dog tail wiggles only slightly at its base but furiously at its tip.
When a decision is not enforced, it leads to many more contradicting projects and features in development. If a decision is not enforced, projects get reprioritized repeatedly. If decisions are reopened weekly, projects get also reprioritized repeatedly. Developers start to work on a feature, just to put the code into hibernation and work on something new. All that code is lost to the company and to customers, the -released- output of development decreases and development is perceived as slow. Reprioritization and pressure lead to developers being moved around to hot spots. When developers need to familiarize themselves with new features and code parts instead of writing code this leads to trashing and productivity plummets. Development output goes down and pressure is increased again. A vicious circle because decisions are not stuck too or enforced.
5.
The decision process in many companies is broken and decision making is seen as a singular event. The effects result in the perception that development is slow. This traps developers and CTOs in a cycle of increasing pressure. Developers fall in the trap of thinking the company decision process is out of their scope. CTOs and developers need to encourage and force the company to a working decision process instead. This will result in faster development with everyone including the founders being much happier.
Top comments (0)