Words mean things. We have to be careful with them. To demonstrate this, I am picking on the word Ownership, which is often utilized in Startups. There is a tendency to pack a lot of meaning into them and then the packet loses information in transit.
For the record, I actually think it is a pretty cool word.
Who is impacted by Ownership
✨ Individual Contributor (IC): It might be something your Startup or Company told you to embody/do more of/feel. You might feel cynical when you hear the word, due to how it is misused.
🔥 Leader: It also sounds like it contributes to burn out for some Tech / Team leads and CTOs. Instead of being able to partition and say, 'This is not my job', you experience 'Everything is my job'.
Questioning Ownership
❓ Why would someone on the team feel Ownership when they don't actually own anything? (barring owning stocks etc., but even then, their portion may be vastly smaller than the Founders) - If you think I am misinterpreting (Owning the company vs. Owning an area of responsibility) then you've already experienced how things can go awry.
❓ Why was the word Ownership chosen? What pain point are you trying to work backwards from? What are you trying to accomplish with it?
❓ What does Ownership mean to an IC? What does it mean to a Leader? Is there a difference between the two?
❓ What does successful Ownership mean? Can you tell someone they succeeded at Ownership, and if not, how will they know they've succeeded?
❓ What does unsuccessful Ownership mean? Can you tell someone they failed at Ownership, and if not, how will they know they've failed?
❓ What is individual Ownership? Team Ownership? Organization Ownership?
❓ What are the boundaries of Ownership? Are the boundaries ill defined? Are they too rigid? How does one person know when they 'Own' something or don't 'Own' something?
🔥Ownership is a Principle, and Principles must be built into Systems to actually Work🔥
Ownership is what I like to call a Principle.
Principles can be a good thing for both Leader and IC. Good for a leader because your input actually has impact, and good for IC because there is far less Ambiguity. The issue is that before anyone can make use of a Principle, it needs to be built into the system of work.
It could look like a Metric that is clearly communicated, tracked, and tied to performance. For example, if you gave someone Ownership of a specific Feature that is tied to a Goal, that is much more specific and actionable than asking them to embody Ownership in an abstract way. Now you have defined a Boundary for them to 'Own'.
What are the inputs? What are the outputs? How does the system of people log information, provide warnings, and throw errors? What context is the system operating in?
✨Working at your Company is a form of User Experience✨
The funny thing about the term 'Developer Experience' for example, is that it sounds an awfully lot like 'User Experience'.
The experience of working at your Company is a form of User Experience. There is a Business System (AKA Business Model) in place whether you intentionally put it together or not.
Let me emphasize that some more:
The experience of working at your Company is a form of User Experience. There is a Business System (AKA Business Model) in place whether you intentionally put it together or not. -Sage
This is complicated stuff, but I believe just like a product, a Business System can be iterated on.
Let us assume that Leader Burnout won the Prioritization game at your last Workshop (Workshops are a whole Software Sage topic for another day):
- Hypothesis: The Principle of Ownership will reduce Leader Burnout by distributing responsibility for specific Features to IC's.
- Experiment: Give specific IC's Ownership of different Features.
- Result: Measure Leader Burnout over time.
If there was a measurable improvement, keep the change. Build the System that works for your Team.
✨Hopefully this helps. Let me know what you think in the comments.✨
Sage's Bookshelf
This is the grab bag of cool things.
📖DevOps: 2024 DORA State of DevOps report out, starting to get some insights into how AI impacts Devs (Some great data in this one, if you are a Software Engineering leader I highly recommend checking these out each year)
📖Startups: Founder Led Companies outperform Other Companies (1 in 10 Companies achieve profitable growth, and the successful ones were disproportionately influenced by the people that Founded them or were still operating by the principles/foundation the Founder instilled into them.)
📖Gen AI: IEEE: Generative AI in the Software Development Lifecycle (A roundtable discussion on AI + SDLC)
📖AI: Author of the 100 pg ML Book is writing a 100 pg LLM Book (Another potentially valuable learning resource)
📖AWS: AWS Amplify Supports Conversational AI (I've been working at becoming an Expert with AWS Amplify lately, and noticed it supports Conversational AI- this is valuable from a UX perspective because developing a UI built from the ground up to support AI is often far better than inserting AI into an existing product. Always exceptions though, sometimes the business can make a case for it.)
📖AI: Whitepaper on LLM Efficiency (There's a lot of talk of going big, but don't let that stop you from taking a step back and thinking about what going small means in the context of LLMs.)
📖AI: Hugging Face Releases Observers: An Open-Source Python Library that Provides Comprehensive Observability for Generative AI APIs (Found a project that supports wrapping LLM APIs so that you can observe them, link to the GitHub here)
📖Trends: Why Polyworking Is The Future Of Work And How To Become A Polyworker (This is here to stay because worker wages don't keep up with inflation and other pressures, so get used to it and learn to adapt to the trend. It supercharges learning- the foundation of inventiveness and critical thinking is a variety in experience and exposure to many problems/ideas/solutions.)
📖App Generation: Bolt: Prompt, Run, Edit & Deploy Web Apps (Lots of attempts at generating entire web-apps. Super crude right now, but will be interesting to see how they tackle this.)
📖Food: No-bake Energy Balls (I've fallen down the rabbit-hole with these, they are super filling, far tastier, and a lot healthier if you do them right compared to the cardboard bars you can buy at the store. A healthy techie is a happier techie. The best part is that you can eat them right out of the freezer, so you can have a super filling snack on the go.)
Building AI: Interested in help building AI & Software? Check out Rosenblatt AI via Website, or check out the Upwork. Let them know I sent you. :)
#startup #cto #ceo #fullstack #fullstackengineering #softwareengineering