How do we make sure that we are deliberate about the culture of our organization and not find ourselves pushing for outcomes without care of how we achieve them?
Jason and Eiso go through the building blocks of positive company culture and explore how companies and leaders can adapt as their teams grow from two people in a garage to thousands of employees. From setting priorities to communicating effectively to operating in first-team mode, there are countless ways engineering leaders can make a difference for their companies. We explore them in this episode of Developing Leadership.
Here are a few of our favorite moments from the conversation
No one talks about your decision-making processes. No one talks about what happens when the site is down. No one talks about, you know, what's going to happen when a customer churns, how the entire company is gonna react. I mean, that's culture right there, those sorts of things.
There's a quote from Maya Angelou, which I talk about generally speaking for leadership, which is: "People will forget what you said, but they'll remember how you made them feel", and when you think about culture and you think about engineering or anything else, this is what you're actually referring to.
There's a joke that I like to say which is that the CEO should be the one who's prioritizing for the company. But ironically, it's the CTO who will probably push most of the prioritization, because that's where it has to happen. The dirty little secret of the industry is that the CTO will, say, prioritize 10 times more than anyone else in the company, and it's because that's where the actual rubber meets the road.
There's an amount of speed that you can get, but speed always comes with its trade-offs. At Athenian, we always say: "You can move really fast, ship lots of features, but your quality is going to suffer. You can have amazing quality, but you're going to have to ship slower, and you're going to have to invest in areas that are not necessarily as customer-facing." And I always like to joke a little bit, it's like CAP theorem and databases, you can only ever have two out of the three. I can have speed and quality, but that means I'm mainly shipping bug fixes. Right? I can have speed and features, but that means my quality is going to suffer.
I think running a company in a division, you would actually have to be a better communicator. You have to understand the psychology of the organization. You have to know how to inspire. You have to have more than one method too. You've got to be X to this group, or Y to this group or Z to this group.
💡 Topic Explainers
🛠 CAP Theorem
The CAP theorem is a belief from theoretical computer science about distributed data stores that claims, in the event of a network failure on a distributed database, it is possible to provide either consistency or availability—but not both.
The CAP Theorem is comprised of three components:
Consistency: All reads receive the most recent write or an error.
Availability: All reads contain data, but it might not be the most recent.
Partition tolerance: The system continues to operate despite network failures (ie; dropped partitions, slow network connections, or unavailable network connections between nodes.)
In normal operations, your data store provides all three functions. But the CAP theorem maintains that when a distributed database experiences a network failure, you can provide either consistency or availability.
It’s a tradeoff. All other times, all three can be provided. But, in the event of a network failure, a choice must be made. source: bmc
🛠 First-team and Second-team Mode
Operating in First-team or Second-team mode is all about a leader's mindset concerning their team, function, and executive group. It's all about alignment and knowing which team you are playing for, first and foremost. Operating in a First-team mode is one way to create a healthier organizational culture, where everyone in the exec room is perfectly aligned and working towards clear goals. Operating in Second-team mode can lead to tensions between different departments in an organization and a lack of alignment in the overall purpose of the company.
As Jason explains in the episode:
What that means is how do they treat the exec room? Do they walk into the exec room and think "I need to go to exec, to present what my team is doing." Their team, being their function. I call that second-team mode. They're treating the exec room as the second team.
If they walk into the exec room and they're treating the exec room as the first team, and they happen to run a function, that's first-team mode. The healthiest executive groups and companies operate in first-team mode. Which is, everyone is their function second, and the company exec first.
🛠 The Pareto Principle
Named after economist Vilfredo Pareto, the Pareto Principle specifies that 80% of consequences come from 20% of the causes, asserting an unequal relationship between inputs and outputs. This principle serves as a general reminder that the relationship between inputs and outputs is not balanced. The Pareto Principle is also known as the Pareto Rule or the 80/20 Rule.
The original observation of the Pareto Principle was linked to the relationship between wealth and population. Pareto observed that 80% of the land in Italy was owned by 20% of the population. After surveying a number of other countries, he found the same applied abroad. For the most part, the Pareto Principle is an observation that things in life are not always distributed evenly. source: investopedia
🛠 PRD: Product Requirements Document
A product requirements document (PRD) defines the requirements of a particular product, including the product’s purpose, features, functionality, and behavior. It serves as a guide for business and technical teams to help build, launch, or market the product. source: atlassian
Developing Leadership is powered by Athenian. We are introducing a winning approach to engineering metrics that can help you empower your teams to autonomously improve. If you want to learn more, go to athenian.com
Share this post