Principled decisions - your team's hidden superpower
Drive product and engineering work efficiently, leverage local leadership
Making principled decisions and using them constantly, on everything - from legacy to new products without non-productive second guesses is a super power. To develop that you need a shortlist of first principles, strong culture and leadership.
The first obstacle to overcome are bureaucratic organizations and siloed functions - think product teams that constantly fights with engineering teams and the other way around. Look for constructs as Agile teams, Project offices, Segregated data science teams and kill them. Let the blame game go away.
Principles are basic building blocks that defend themselves. You probably have a set of principles that you try to convince others that are great. Do an assessment of which principles can explain themselves, which one are irrelevant and of these two sets which principles were easy to sell ou already there.
To help explain my point, the principles below are the ones I like to use with both engineering and product teams:
Do the simplest thing first
Establish visibility: less than 5 metrics that explain business and product start to end
Work backwards, from customer to implementation. Avoid bit rounds of prioritization, discovery or politics driven backlogs.
Start with a boring stack, be opinionated, ship a lot and then add tools as needed.
Do not separate work by people specialty - split them by proficiency: blocked work waiting for front or backend engineers availability is silly. Data engineering blocking data science work doesn't makes sense, product management vs discovery delays takes credibility out of the team.
Address the deadline taboo - Write a press release, a FAQ, set a date with the team, push for the reasonable unit of work and customer-efficient deliverable, stop when the discussion moves from “What” to “How”.
Have clarity on what you are doing: running the business, second level support or new features.
These are not optional, interchangeable or items to be deprioritized: Quality, Security, Performance
The first principle guide the others: “Do the simple thing first”. It makes it possible to unblock work so individuals and teams move faster and perceive that prioritization is the what holds them back, not tooling, not programming languages. The rest of them were lessons learned as a way to aggressively avoid what can take credibility and energy from teams.
Principled decisions are just that, decisions that follow principles. If we spend too much time discussing frameworks and forget to ship, we become a liability - we lose the shipping muscles, and generate no impact.
If we spend time discussing who should run which service, we won't spend time running, understanding why and what we have to build. The last layoffs proved that you don't want to be in this place.
Once we become frugal and focused, we make time to advance and ship. That's the Autonomy everyone looks for.
Platforms and principled decisions
Platforms are a form of principled engineering decisions that are exhaustively exercised. Every day, for sometimes more than 1000 times a day if you are talking about production platforms, CI/CD, deployment pipelines.
They are fixed and improved when they needed to, second guessed the same but never thrown away for the next shinny framework or methodology. Platforms start as a thing of the team, not of a single person trying to push through hardships. Not perfect, but evolving because they needed to talk about what they were building more than how they would like to build.
Meta has their own container runtime and orchestration, called Twine. All developer machines have their Twine client setup and an alias for the docker command that points to their own internal tooling. Every season there are new developers questioning it, trying to push docker before understanding what and why is there and when they become productive, they understand. and then they contribute. That's a platform coming from a principled decision.
Amazon advertises their “Working Backwards” methodology and lack of slides on meetings, resorting to written prose to describe products, release and so on. Every new leader might wonder how to improve that but some try to change that to implement program management, project offices and other methodologies. Same as any engineering tool. Not perfect but rooted on culture.
Closing
Platform, and the principles they are derived won't happen with a top down mandate, as much as we want to believe it does. A mandate helps but strong culture drives adoption.
Anyone can propose a new way of doing X but selling, running it and being successful is what usually adds as career impact, specially on leadership. Remember that leading and managing are not the same thing.
The lack of such signs drags all associated functions - product, data, design - into a void of complaining and not shipping, making it logical to second guess investments made on technology.
Get your shortlist ready and make an exercise of how many of your principles are shared by your team, driven by people that are not you and helped compose platforms. Also note the ones you left behind just because there were better alternatives. Assess the impact of both group and you will understand which culture is in place.
I wrote a book called The CTO Field Guide. It is a book to help product and engineering leaders of all levels. Check it out at https://ctofieldguide.com.