The Framing of the Developer

The Framing of the Developer

2020

Who framed Roger Rabbit? Talking about Software Development in companies is about using frames. The prevalent frame is the that of the 'Backlog'. Thinking in this frame defines success as finishing the backlog. The pressure of throughput leads to engineering cutting corners and makes developers unhappy. Thinking in an 'Impact' frame leads to more successful company and happier developers.

The internet brought many changes to software development. Duh! The rise of the internet company drove the need for continuously watching the market and listening to the customer. Software development could no longer happen in isolation and take long periods of time. The market has moved on, competitors didn’t spring up every decade but every month. And most of these were well funded and not garage shop operations. The overall drive was to focus more on developers with faster changes and more intermediate steering instead of charting long journeys.

The first method to reflect this was Extreme Programming (XP) at the end of the 90s. XP brought agile and iterative development to many developers and introduced the concept of “On site customer”. The idea is to have a customer available to the development team, best to have the customer on site and available face to face. It was then the task of developers to ask the customer about details and what needs to be developed. This put developers in the driver seat and the customer ensured that the right things were built in the right way. XP failed. It probably failed for various reasons, but one being that the internet brought companies with millions of customers and XP was born in an environment of internal software development. It was challenging to get a customer onsite. The other reason might be that developers could not “just develop” code but responsibility for a successful product was put on them. They were expected to be in the driver seat and interact with customers.

Then Scrum arrived. Scrum was very different from extreme programming. It didn’t tell developers what to do. Where XP said developers should do pair programming for various reasons, Scrum didn’t care. Where XP told developers to unit test, Scrum didn’t care. Where XP told developers to take responsibility for what is being build, Scrum told developers to take responsibility for throughput and deadlines. Scrum looked at the management of things to build and how people should interact. It brought a strict guide to meetings and what to do in those. But Scrum doesn’t care about engineering. The most impactful change Scrum brought was the product owner. The team no longer owned the product, but the product owner did. He decided what the developers should work on. The developer was no longer in the driver seat. It wasn’t the developers asking the customer what a product should look like but the product owner telling them what features he wanted. Most were probably happy with the change – also because salaries started their meteoric rise.

A new protagonist entered the stage – the product manager. Successful companies were using them and so everyone followed. Agile and the rise of product managers went hand in hand. The move from a top down, command hierarchy to self-organized teams brought the need to interact with this team and give it work. Before that time products would be discussed on the board with the CTO and then handed down, poured into projects and given to developers. With the rise of agile and self-organized teams this flow of work no longer worked, and we needed a new setup. With the advent of data analytics into product development the need for optimizing KPIs like conversion shifted gear and someone was needed to do all these jobs and developers were unwilling. They would not be interested in the business side of the company. With whom would business speak to get its features done? Business thought developers were hard to talk to. So, product managers filled the gap. Luckily with the rise of Scrum we also had an organizational structure to easily fit the product manager in. Product owners! From then on, the product owner role in Scrum nearly always is filled with the job description of a product manager. Today these two are often confused and used synonymously. Most people no longer realize that product owner and product management are two different things.

Developers were happy in the short term they didn’t need to speak to customers and had someone clearly responsible for what to build. The product owner could do all the messy things like talking to marketing and sales and manage requirements. But developers were no longer in control. Feeling in control is one of the main drivers for happiness. Although everyone flatters developers, they are in high demand and salaries rise and rise, they feel less and less happy building stuff they don’t understand, have no impact or that doesn’t make sense.

In an article titled “Extremely disillusioned with technology. Please help“ an unknown engineer wrote “Then I worked for a tech giant, and then for a high-growth unicorn. It shocked me how dilbertesque they both were. Full of politicians and burnt out engineers in golden handcuffs who can't wait to get out, and meaningless business speak, and checked out employees who pretend they're "excited" about everything all the time.”‍

Now is the time for change.

Don’t think of an elephant! That’s the title of a book about framing. Elephants? Framing? If I tell you to not think of an elephant, you will think of an elephant. The elephant is the frame of your thinking. The “elephant” activates your framing. The frame anchors discussions to the elephant. While the book focuses on frames in political discussions, the concept applies to every environment with different ways to see the world:

“In the social sciences, framing comprises a set of concepts and theoretical perspectives on how individuals, groups, and societies, organize, perceive, and communicate about reality.” Wikipedia

Framing is intentionally and unintentionally used in discussions and environments. A frame shapes the discussion and makes some things thinkable and some other things unthinkable. Frames have friends that go with them.

We have a dominant frame in development. Software development as a “backlog”. Features are put in a backlog by a product manager – the product owner – and by different departments. According to the Cambridge dictionary a backlog is “a large number of things that you should have done before and must do now”. The word backlog makes you think you are always behind finishing things. The frame says: Finishing means success. If we work from the backlog, we’ll have success. If we complete all the things I as a product owner have in my vision, we will have success.

This frame was latently there all the time. With the rise of the product owner and the backlog tool in Scrum, this frame was made explicit and has manifested and solidified itself. The product manager filled the gap between developers and business, between technology and the CEO. The backlog as a tool helped manage these relationships. As the owner of the backlog, the product manager is using this frame in conversations with technology, business, founders and the CEO.

In the backlog frame success is tied to implementing the items of the backlog. There is a need to implement the items for success. If a product isn’t successful in this model, then not enough items from the backlog have been implemented. So, it is essential to work as fast and efficient as possible, because this drives success. CEOs often ask me why their developers don’t work as long as marketing. They think success of their startup is tied to developers working late into the night. The more features from the backlog, the more success we have. This brings the buy in from the CTO. The more developers we have, the more features we can implement and the more success we will have. In this world view developers are treated as a resource. The more of them the better, the more efficient the resource is used the better.

In the backlog frame the idea of technology is to execute and deliver. Often CTOs are proud of delivering. If there are problems CEOs think “Tech didn’t deliver” and problems arise because “IT is too slow”. Contrary to that developers think that product managers need to tell them what to work on, they are not responsible for success. If a product fails, product didn’t tell them to work on the right things. Funnily only developers think this way, everyone else things “technology did not deliver”.

If a product succeeds, it’s due to the vision of the product manager though. If a product fails in this frame, it is because we have not implemented the whole vision of the product manager. If developers would have been more efficient, worked more or there would have been more of them, then there would have been success. Success and failure are neatly separated. No wonder this frame is so successful.

The pressure of success in this frame leads to discussions of developers cutting corners. Does this implementation really need to be this complete or complex? Do we need security now? What if we cut testing to a minimum or - always just for this product release – don’t do it at all, so we can implement more features and make success more likely? Don’t you want the startup to survive? Don’t you want success? Development is cut to the minimum to deliver “value” and engineering best practices are thrown out of the window, never to come back. Engineers adapt to this frame. We as engineers have invented the term “technical debt” because it sounds better than cutting corners and with the hope it is repaid. We already cut best practices in our head to deliver more features, calming us with “technical debt” that will be repaid sometime in the future. Funnily developers think “technical debt” means something that needs to be paid back by a product manager with time to clean up. Businesspeople think technical dept sounds like what it is, technology has debt that it needs to pay back because it cut corners. I always wondered why it isn’t called “product debt” because product took the credit to get a feature faster and must pay back by investing the time to clean up. Technology is the bank that gave credit. What is wrong with this frame in general? If the iPhone was brought to market two months later nothing would be different.

The iPhone still would have changed the world. Apple still would be one of the most valuable companies. If Apple hadn’t released the iPhone, the world would be different, Steve Jobs would not have the impact on the world he had. Efficiency was not the key to success, delivering all the features was not key to success. The first iPhone lacked many of the features we take as common today, like the app store. The key to success was doing the right thing, focusing on impact not on efficiency. Steve Jobs wanted to change the phone market with the iPhone. The iPhone was not built to a backlog of a laundry list of Apple departments.

Companies today need a frame of impact. In this world view success is defined by impact. Do product and technology develop products and features that have impact? Impact means impact for the company and impact for the customers. For the company this feature, or product moves the needle. For customers it changes their behavior. Take Pipedrive. Pipedrive is a sales SaaS company helping companies make sales. Salespeople using Pipedrive change their behavior to funnel thinking. Pipedrive has impact on their day to day operations.

In the “Impact” frame product managers talk to business, technology and the CEO about impact and no longer about efficiency, number of developers, throughput, deadlines and backlogs. This means we need to do things that have impact and no longer focus on things that have no impact. Most companies I have seen are working mostly on things that are demanded by departments or are ideas of product managers that they have come to love. When I ask CEOs how this or that feature impacts their company or their customers, they answer that they don’t know, but these things “need to be done”. Most probably to satisfy someone in the company. Some of them don’t develop for the market but for their investors. When I ask them, what would happen if they don’t build those things, they don’t know either. The impact frame helps to focus on the important things. If success is defined by throughput and finishing a backlog, the more things you do the more successful you are - which leads to many features developed that are not important to customers. Backlog success is input driven product development. It focuses on the input. Impact development is outcome driven. It focuses on outcome.

Failure is when we don’t have impact. In this frame it becomes crucial to choose things that have impact and not work on things that do not have impact. It is key to throw away most of the ideas you have and only stick with the very few that will change your customer or the market. You need to have rituals like Poppers falsification: How can we throw out ideas at the idea stage? Who is throwing them out? Do we throw out 90% of our ideas or are we building 90% of our ideas? Also throw out ideas that are already in development. You’ve put time, energy and money into something and learned that it will not have impact? Stop! Throw it out. There is a large list of things Apple developed but didn’t bring to market – it is ok to throw away things that have no impact. I never saw companies throw away products or features mid-development because they’ve learned the feature will have no impact – oh the wasted resources! The efficiency frame prevents us to throw away things mid-development.

On the surface we already do this with OKRs, user stories and KPIs. OKRs should help a company focus on key results, user stories should bring the customer perspective into the center, KPIs should measure our impact. But in reality, we still end up in the backlog frame. People have learned their ways to combine the backlog frame with OKRs, user stories and KPIs.

To come back to the unknown engineer who pleaded for help. Developers are happier with an impact frame: They work on things that have impact and they have more control when they help throw out ideas. The impact frame is not throughput oriented and all the negative consequences of the backlog frame go away. There is no cutting corners or neglecting good engineering practices. The impact frame doesn't split responsibility for success and failure. The impact frame leads to more successful companies. Now is the time for change.