Every post I add a character that inspires me. Today, Adele Goldberg. Women were pioneers in computer science and Adele's contribution to the science is remarkable. Her ideas were foundational to what latter became object-oriented programming and design patterns. Awesome!
There is no way to escape it. Your software is your competitive advantage, no matter what you do. Andreesen's prophecy that software is eating the world is here.
In this world, a fundamental question comes to mind: how are you treating developers? They are the ones actually doing the stuff, if their experience is bad your product will be bad. Even if you hire great engineers, great code to a bad product does not make it better. And those engineers will be soon jump off the boat if their experience is bad.
If you want to transform your organization towards innovation and great products, apart from corporate courage you need to see technology as central and empower your engineers.
I always tell product managers that their main role is to (i) build trust among the team, (ii) create a healthy process that empower engineers and designers to find the best solutions to well defined problems, (iii) communicate changes and vision across the board (with the help of management when needed) to mitigate business value risk.
The worst thing that happens in a company is a rollback because of misalignment with the rest of the company and/or leadership - I think nothing frustrates engineers more than this. Avoid it at all cost or you might lose trust.
If you are a product manager, work hard to keep the development team engaged. In my experience there are some actions that help on that:
Avoid putting much pressure on the team whenestimating the release of something.
The job of a product manager and tech lead is exactly to scope the problem based on how much time we can invest on it or the necessity of the business. A ball park estimation usually works fine.Give engineers time to build tools that help them improve their productivity.
Sometimes small tweaks on code or a new deploy script can save a lot of time and hassle when compiling or deploying the code. Give them space to think and act on it. It's central.Never skip retros.
Good retros are the best way to develop psychological safety among engineers and develop continuous improvements on team management. It's the basics of high-performing teams.Include engineers early in the loop.
You will reduce feasibility risk and make communication easy - engineers will see the problem first hand. Start together.Highlight bottlenecks and problems in productivity to top management.
If you are running good retros you will identify some common problems - the DBA teams does not answer us, the CI/CD pipeline is too slow, deploy the code is a hell, our legacy code sucks. Highlight those to top management and try to help findind the solutions. Believe me, any small improvement will be huge to developer effectiveness.
Always be curious.
Thanks for reading!