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”.