SPaMCAST 768 – Teams, SaaS, Entrepreneurship, A Conversation with Phil Alves

The Software Process and Measurement Cast 768 features our interview with Phil Alves, CEO of DevSquad. Phil and I covered a wide range of topics starting with how he structures teams to perform in dynamic environments and culminating in a discussion of SaaS and entrepreneurship. Software development of any stripe is a team sport; either get it right or suffer the consequences. 

Phil describes himself as a SaaS Aficionado! 

He builds products for bootstrapped founders, fast-growing startups, and big enterprises at DevSquad.

His SaaS company, DevStats, helps product and engineering leaders measure what matters.

Phil also is a podcaster!  The SaaS Origin Stories Podcast uncovers those pivotal moments and decisions that turned SaaS companies into major successes.

Contact Information

DevSquad: 𝒉𝒕𝒕𝒑://𝒅𝒆𝒗𝒔𝒒𝒖𝒂𝒅.𝒄𝒐𝒎/

DevStats: 𝐡𝐭𝐭𝐩𝐬://𝐝𝐞𝐯𝐬𝐭𝐚𝐭𝐬.𝐜𝐨𝐦/

Podcast: 𝒉𝒕𝒕𝒑𝒔://𝒘𝒘𝒘.𝒔𝒂𝒂𝒔𝒐𝒓𝒊𝒈𝒊𝒏𝒔𝒕𝒐𝒓𝒊𝒆𝒔.𝒄𝒐𝒎/𝒔𝒖𝒃𝒔𝒄𝒓𝒊𝒃𝒆 

 

SPaMCAST 760 – Alignment and People, An Interview With Jonathan Hensley

SPaMCAST 760 will feature an interview with Jonathan Hensley, Founder & CEO at EMERGE. Jonathan and I talked about digital transformations and engagement. The core boils down to people and alignment. This was an extremely refreshing interview!  Let me know what you think.

Jonathon Hensley is co-founder and CEO of Emerge, a digital product consulting firm that works with companies to improve operational agility and customer experience. For more than two decades, Jonathon has helped startups, Fortune 100 brands, technology leaders, large regional health networks, non-profit organizations, and more, transform their businesses by turning strategy, user needs, and new technologies into valuable digital products and services. Jonathon writes and speaks about his experiences and insights from his career, and regularly hosts in-depth interviews with business leaders and industry insiders. He lives in the Pacific Northwest with his wife and two boys.

linkedin.com/in/jonathonhensley

emergeinteractive.com (Company)

productalignment.com (Company)

emergemobilefirst.com (Mobile First Podcast)

 

Hierarchy, Fatalism, And Engagement Are Intertwined – Reactions

he ideas of hierarchy, engagement, and fatalism struck a nerve within the SPaMCAST family. To a person, the prevailing attitude is that hierarchy has value but only to a point. Susan Parente identified that hierarchies are valuable for “quick decision-making and action”. A well-understood and compact chain of control that does not need a Google search to determine who can make a decision is useful. The caveats to the term “useful” include understood and compact.  In the same breath, to a person, they all agreed that while some hierarchy is good, too much is not. Hierarchies grow until they find a tipping point where they become too heavy or too stolid and protective. Past a certain point, they dampen engagement and yield mediocrity without intervention. There are all sorts of good reasons for organizations to react in this fashion. But mediocrity in a competitive environment is a harbinger of a death spiral. As Keis Kostaci, (SPaMCAST’s newest columnist) stated, “Hierarchy can hinder engagement and especially when those people/individuals that need to speak out get shut down.”

 

Hierarchy, Fatalism, And Engagement Are Intertwined

Fatalism in the workplace is the belief that you can’t control or influence the work you do or how you do it. Engagement is a measure of commitment, motivation, and involvement. Engagement impacts a person’s work, their colleagues, and their organization. An engaged person is passionate about their work. With few exceptions, hierarchy is a fact of life. Hierarchy defines the levels of authority, responsibility, and decision-making within a company or organization. A simpler definition that is often used is the “chain of command.”

 

Privilege and Fatalism

I have been considering the relationship between privilege and fatalism. Boiling down the impact of privilege into a few words, we find advantage and the potential for power. Whether it is the ability to make decisions about the work you will do, the power to direct others to do work, or even just to be heard, privilege is power. That power can generate fatalism in those without the power privilege delivers. As an agile coach, the concepts of privilege and fatalism often collide. Early in my career, a mentor passed on a piece of advice. If you have a great idea, have a consultant tell it to my boss (my mentor’s boss). They will accept it from them, not from you or me. The consultants had privilege. The message was clear, we did not and wouldn’t be listened to. This is an example of a collision of fatalism and privilege. This was of course despite our corporate mottos “we only hire the best and brightest” and “our employees are our greatest assets” which were emblazoned on posters in the lunch room. Looking back it is hard to understand how that amount of cognitive dissonance was tolerable.  I am now on the other side of that coin. Where power differentials exist and are used as a tool to gather power then privilege and fatalism run wild.

 

A Few Approaches For Combatting Fatalism In Organizational Change

Some of the most celebrated stories in business literature are where people did not accept the rules or others believed that they were not empowered to act and acted. One of my favorites tells the story of a Federal Express (before it was FedEx) employee.  They picked up the whole drop-off box and took it back to the station because their key wouldn’t work. They acted and accepted responsibility for their behavior. Years ago a friend and colleague paid with their career. My friend approved an emergency change to a department’s website when it went down. The change went to production without going through the change control board which would have taken several days to meet. They knew what they had to do, the failure put lives at risk (it is a cool story) and there would be serious consequences. The person in both stories did not accept that something was outside of their control, acted, and pushed forward. 

 

Fatalstim in Change

A few weeks ago a colleague and I were discussing why a team never had anything to show during the demo part of their sprint review. The team works on a large number of small to medium size enhancements. The work is important to the business, so as soon as it is ready they get approval and promote it into production. At the end of the sprint, there is nothing for show and tell. I suggested that the duration of the sprint was too long. A shorter sprint would afford a chance to gather broader feedback before moving the work into production.  The discussion went something like this:

 

SPaMCAST 755 – Engagement, Hierarchy, and Fatalism, Making Mistakes, Essays and Conversations

SPaMCAST 755 features an essay on the relationship between engagement, hierarchy, and fatalism based on a discussion of the topic between the SPaMCAST Columnists. The ideas of hierarchy, engagement, and fatalism struck a nerve within the SPaMCAST family. To a person, the prevailing attitude is that hierarchy has value, but only to a point. 

Jon M Quigley joins the cast in the second slot this week with a discussion about making mistakes. Learning from mistakes is important but making the same mistake over and over is not a sign that you are learning. /

 

Team Topologies, Re-read Saturday, Week 1, Logistics and Front Matter

Today we begin the re-read of Team Topologies: Organizing Business And Technology Teams For Fast Flow by Matthew Skelton and Manuel Pais. The book contains front matter, including a foreword and preface (22 pages), 8 chapters, a conclusion (190 pages), and end matter (glossary, recommended reading, references, notes, index, acknowledgments, and about the authors).

 

Addressing Transactive Memory Risks On Agile Teams

If we agree that transactive memory is a common feature of teams’ institutional memory and accept the benefits, then we must address the risks. That should not be a major assumption. In many situations it makes sense. Knowledge can be stored in a single place and then accessed by the team as needed. The idea of having one version of data was one of the reasons I was taught normalization when I was working in the database realm. Transactive memory acts as a form of normalization so teams can reduce redundancy and conflicting truths. When the process works, a team will be more than the sum of its parts. While this seems very mechanistic, I would not suggest ignoring the idea in a fit of humanistic pique. I have not found a team or relationship that has been together for more than a few days that is not leveraging transactive memory. However, as described in our overview, there are two macro scenarios where transactive memory causes problems for a team adopting new approaches. They are: