Lessons Learned from a Fortune 25 Company

Fresh out of a series B SaaS start up I looked onward for a new role to expand my toolset as a product minded person. I had just been a product manager at an incredibly underwhelming startup where engineering throughput was laughable, executive leadership was like the JV football team (with exception of our sales team), and my bosses boss had run off or fired 100% of the product managers at the company – and now it was time to look for something new, and, hopefully something exciting.

What I had stumbled across was a role at a shit hole company called Anthem as a Product Owner. Truthfully, when I was interviewing I had no idea what Anthem even was, I was only familiar with the “Blue Cross Blue Shield” brand. As I went further into the interview process I realized that Anthem was the antithesis of what the startup was with respect to size and corporate structure. So going in, I knew it would be a different dynamic, one I was not seasoned in. I also knew the role I would be taking on would be the first time I’ve ever done it. What the hell even is a Product Owner? In essence, a Product Owner stresses about the details of product development as it pertains to business value and delivery/execution. The Product Manager is the one who sits back with a beer and thinks about the high level feature, the problem being solved, the customers impacted, etc. One focuses on details and misery, the other focuses on high level thinking so they can offload work to everyone else: engineering, their PO, design, etc. It’s a crude high level summary but there is validity in it sadly. One is in the weeds (PO) and the other is a dreamer that offloads the delivery work to others (PM).

Back to the topic at hand – so, going in I knew things would be different: size of the company, the role, etc. The biggest thing I wasn’t ready for was the idea that if you’re less than a certain title you’re a worthless shit stain that shouldn’t breath. Meaning, if you aren’t a director or above them (SVP or VP), the percent chance of you getting something changed was close to 0. From week one I observed the hierarchical nature of the company. Most people at that company were in it for the long haul (at least by standards of techies that jump ship every few years to a newer, sexier, more compensating FAANG or equivalent). It wasn’t uncommon to come across people who 1) hated their life and 2) were at Anthem for more than 2 decades. Sadly, what brought people together was complaining about how much they disliked their job and drinking later in the evening to alleviate the pain.

I know a lot of people joke about drinking and hating their job, but when talking about depression drinking unites people at a fragmented company with low morale – not the product, not the customers, not the love of something healthy -, SOMETHING is wrong… Instead of rambling around random issues I have from the casual depression drinking, or the project losers, or other things, let me put my biggest pain points/lessons in a cohesive list (in no order, mainly because I’m lazy):

Top Pain Points/Lessons Learned:

1. Too many cooks in the kitchen

One thing I noticed very early on at Anthem was the amount of worthless idiots in the room at any given time. For example, there was some issue with a letter not going out for Texas Medicaid and there were 9 people in the call. Of the 9, almost 50% of the people in the call had little to no value being there. A project manager, a senior project manager, an analyst whose system wasn’t even in question, and beautifully, with all of those people in the call, the correct people that were needed to resolve the issue didn’t get an invite. At Anthem it felt like there were too many people facilitating problem resolution than actually conducting the resolution of the problem. Think about it like this, lets say there is a massive rock at our feet that is blocking the drain. This drain is the passage way for all of Earth’s water supply – if the rock continues to block the drain before the next storm, everyone on Earth dies. So, what is Anthem’s approach to solving this problem?

Project losers!

What Anthem will do is bring in people that no one really knows what they do: “Project Managers”, “Experience Owners”, “Business Information Consultants”, and these people will come in and look at the rock and say, “Does anyone know who we need to engage to get this moved?” The person next to the first clueless idiot that asked the question will say, “hmm, let me pull in compliance and see if they know”. Once the loser from compliance gets to the blocked drain, half a Scrum train has been invited and this clogged drain has 343 invited to its unclogging. Instead of getting the right people – 2 people in total – we somehow place a massive administrative burden worth hundreds of hours: emails, invites, meetings, questions that detract from actual work getting done, etc. And the most Anthem part of it all, it turns out the drain in question actually needed to be blocked as per a discussion 9 years ago. It turns out, if this drain in particular isn’t blocked all of Earth dies…

My point is, it didn’t feel like we were doing work whenever work fell outside of my immediate Scrum team. It felt like working with other teams was such a massive effort because we didn’t have leadership that transcended teams on different trains, different business units, etc. Going back to analogy land, it felt like we were playing 5 on 5 basketball and our team had 4 JV players and LeBron James as the 5th player. Instead of engaging our BEST player, our coach made us pass the ball 7 times before we took a shot. What should have happened was, we should have played the game “get it to LeBron ASAP” and make sure the most competent members are getting the work done as soon as possible.

Lesson Learned: Be weary of cultures where you are in a room and you have to ask yourself, “what the hell do half these people even do?” – odds are, most of them are worthless and the executive leaders that created the team structure are oblivious morons too. The morons aren’t at fault, they were hired and arranged in team’s that were doomed to fail.

(coming back to this one year later to finish) (WOW I said idiots and moron a lot… sadly it’s all true)

2. Not enough understanding of the bigger picture (and the systems that wrote that picture)

One big issue I had at Anthem was that there were MASSIVE systems – systems built by thousands of people in the span of a decade (or more!). The issue this caused is that few people actually knew how a system worked with respect to other systems or with respect to a highly specific use case. The architects of the system moved on, the documentation was close to 0, and when you have events like mass layoffs, all of that institutional knowledge is severed (literally).

When you think about someone’s daily or weekly workload, so much of their time is spent trying to understand how do I do this or that? Which teams do I need to engage? Is this even our team’s issue? Are we rightfully at fault for this issue or is it a different system causing this issue. Sure, one could argue – “don’t you have business and systems analysts that know these systems?”. Two parts to that:

1. Many of these people had been churned through and we were dealing with new analysts who asked other clueless people about the systems

Lesson Learned: When you join a new role, try to find a knowledge base that explains systems, that has diagrams, so that as you onboard you can quickly answer questions because you know the systems and people to engage.

Lesson Learned #2: IF YOU WORK AT A LARGE COMPANY AND MANAGE TEAM’S/PEOPLE MAKE IT A PRIORITY TO DOCUMENT WHAT IT IS YOU DO! This isn’t to make yourself look good, this is because good people are likely to leave for start ups, business school ,etc and you need to make sure you can pass off knowledge to the next person quickly. It’s a serious efficiency risk when each time you hire someone they spend 6 months trying to learn what their job’s full responsibilities entail.

3. CYA culture is a canary in the coal mine – RUN!

Truthfully, before joining Anthem I didn’t know what CYA meant. It didn’t take long for that to change. In a Cover Your Ass (CYA) culture people are doing work for their own immediate protection. They do what needs to get done so they don’t look bad in front of their boss, they can’t be blamed, and so that they can do as little work as possible.

A CYA culture is indicative of mediocrity. People aren’t solving complex problems for the benefit of the customer – more likely, people are taking the path of least work so that they can lay low, collect a paycheck, and make it to the next happy hour where they can complain about their boss, their company, and their co-workers. After having worked at a few software startups I know the difference between CYA culture and “by all means necessary” culture.

In a by all means necessary culture you get shit done because you’re passionate and energetic. You aren’t scared or fearful of your boss or punishments. You work late because you want to achieve a bigger goal to deliver a product you’re passionate about.

Lesson Learned: When interviewing, learn as quickly as possible if people are CYA or Malcolm X minded. If they are CYA, make sure you’re interviewing for a C-suite position so you can clean ship, otherwise, RUN!

4. Know when to throw in the towel

The truth is, there are some things you cannot change. If you’re an entry level person, it’s unlikely you’ll be able to enact structural change around a massive company. There is a chance you could, but I’d argue there is a greater chance you’ll expend immense energy and get nowhere – effectively defeating and burning yourself out. You have to know what battles you can fight, which you can’t, and where you’ll draw the line.

One of the reasons it’s so important to try to propel yourself and “get ahead” is that the higher position you have, the more responsibility you have, and the more you get paid, can all help you when throwing the towel in and finding a new job. If you’re a “senior product manager” versus a “product manager” at your old job you’ll catch more attention in the job market with the more senior title (it’s indicative of more knowledge and responsibility than the junior title). If you had more responsibility in your old job your resume bullet points will be more enticing when you can talk about the things you managed and the outcomes you delivered. And of course, the more money you make (and save!) can help you quite a job and search on the job market for months without fear of going bankrupt.

Lesson Learned: It isn’t pretty, but if you’re a passionate person, sometimes it’s worth leaving your job and finding greener pastures. One thing to note, you could actually be the issue and the environment change won’t help. If you’re the toxic team member don’t be delusional and think a new job will fix everything… If you’re confident the situation you’re in is doomed, just leave.

The value of cross functional product teams: Call of Duty pooping on moms

Problem Statement 1: Assuming you have a critical mass of players on your Call of Duty server, how would you optimally allocate players that are looking to join a live multiplayer game (lobby or game that is in progress) such that you minimize wait time and maximize the player’s experience? This type of question has an extremely technical solution but the end result makes players want to play your game ($), harass their friends to buy the game (viral marketing ($$)), and of course make more in game purchases for things that add nearly zero economic value to the player’s life other than making them feel special that they have a tiger skin add on for their sniper rifle that they are already questionable with….

I’m not an engineer but I can already get a sense of ideas and potential solutions for this type of problem: that there will be some type of queues used to hold players, a partitioning of queues to account for skill – which will invoke developers to think about an “elo” system to make sure professional players don’t match with a noob like your grandmother who can barely hold the controller -, logic to account for what to do when the server is overloaded (8pm/on the weekends), an algorithm that determines which players go into which queues based on skill (elo), the strength of your connection to the server (ping), etc etc. In a traditional Agile shop there would be immense detail on the engineering of the product and making sure the server/algorithm/solution works from a technical point of view; but what about the game working from a human point of view? What does that even mean? Let’s think about a different problem statement that a product manager would ultimately be accountable for.

Problem Statement 2: How can we prevent users of the game from being told that another user is going to “take a shit on your mom’s chest”? This sounds like a joke but Modern Warfare, and many other Call of Duty’s, have been plagued by the verbal abuse both in game and in pre-game lobbies of their communities more toxic players. While engineering solutions might be elegant to make the game work, it is clear the game is more than just a product of intelligent and gifted back-end engineers and other considerations have to be made when shipping the product – the game is the sum of the experience of the end user and elegant engineering by itself doesn’t guarantee the game and the experience of the members will be great. It’s all well and good that you can connect to a server, that you can queue up and get into a lobby with players of comparable skill, with a connection that yields a playable experience, but what about the people threatening to poop on your mother? Is that a good experience for the 17 year old boy coming home from basketball practice? Technically the game works but do I really want to get on a server and play a competitive game when I’m hearing people scream the N word and listening to mothers being attacked?

I write this quick post because I believe this is a great mini case to think about where engineering alone is not good enough. You have to work with talented engineers that can work on making the game playable from a technical point of view, but you also have to worry about the non-engineering parts of the game that can degrade the user experience. Everyone talks about the “user experience” and it gets boring to listen to but if customers don’t want to play your game because of a toxic community where people are called the n word, moms are being threatened to be pooped on, and people are threatened to be murdered, how does that affect the video game as a business that can generate cash? I doubt that type of experience is optimal for running a business and that negative user experience kills the business’s ability to be the best it can be. The non-engineering details matter too. Input of non-technical members matter and can prevent billions of dollars from being lost and even generate billions if considered as seriously as engineering input.

The Different Universes of Business

This is going to be hard to write without coming off with an erudite and classist tone, but this theme kept coming up in my mind the first two weeks of work in my first role out of college. To understand my thought process, it is probably most useful to understand what I’m used to. In college, the standard was one of a few things for new graduates: graduate school (masters, JD, MD), investment banking, management consulting, technology, non-profit work, and that’s about it. Those are the paths that a vast majority of people went on. If you were to veer off that path and land at a company that isn’t tech or well regarded within finance, you would be judged in small groups. It was expected that a computer science major lands at a big brand name company like Facebook, Dropbox, Amazon, etc, and that an economics major would land at a big brand name company like Goldman Sachs, Bain, Accenture, etc. Alongside those expectations, there was an expectation for what new grads would make. Because people were getting jobs, and offers, quite regularly from these big companies the salary expectation for new grads was set at about ~$80,000 in finance and +$100,000 in technology. To veer outside of these companies within finance and tech, and to veer outside of these salary numbers would cause you to be an outsider where you would be looked down upon. The last layer on top of all of this is mobility. The expectation is that you would start at ~$100,000 and increase your salary overtime as you gain more experience. In groups, people would talk about how long it would take to get to “400k” salary.

The reason all of this was on my mind is because I’ve been fortunate enough to see and work with a different group of people. These are people at my current company who work tremendously hard, who want to learn, bring energy to their role, and strive to get better. This sounds like most work environments – people come to learn, work hard, and get better; the thing that is different about this environment is that these people have families, kids, and are +10 years in their careers as salespeople. There is nothing wrong with that, in fact, I have tremendous amounts of respect for the people that I work with because they are working hard, learning, and supporting families at jobs they probably don’t love. They are most likely making under $65,000 at 10-15 years into their careers but they come with intensity, laughter, and joy to their job. They respect what they do, they work hard, and take pride in their work.

I came from a place at a college where these people I work with would be laughed at, mocked, and looked down upon. The reason for this is due to what those types of college kids expect. As described earlier, the kids that go to these private colleges in the northeast expect a certain salary, in a certain industry, with a certain amount of career progression with respect to title and compensation. As a peer to these college kids, if you’re making $40,000 a year at a not very prestigious company, you’ll be judged to some extent. But imagine how you’d be judged if you worked hard for 7 years and your salary only went to $65,000 and you didn’t achieve the mobility your peers expect. You’d be thought of as inferior and a waste of potential. As cancerous as it sounds, it’s true with people that I’m describing.

The thing that bothers me about all of this is that the people I work with will, and do, get judged by the “type” of people I went to school with. The people I work with would be seen as inferior from the perspective of the new grad kid that gets into Google or Goldman Sachs out of school. I’m happy that I didn’t get a place like Google or Goldman handed to me at the start of my career. There are people in this world who weren’t privileged and lucky to have the opportunity that comes from a prestigious college in the northeast, and despite this lack of luck and privilege, these people work hard, take pride in their work, and are 100% as human as these classist, erudite bitch kids. I’m glad I was given a glimpse of what things are like outside of Silicon Valley and Wall Street. There are people that don’t have a prestigious degree who work harder, are nicer, and want to make just the same (if not bigger) impact! I’m proud to work with the people that didn’t have these same opportunities, who raise their families paycheck to paycheck, and are thankful for the opportunities they have – even if those opportunities are perceived as depressingly bad in the eyes of “erudite bitch kids”.

The day I act like one of these “E-B-K’s” is the day I need to reevaluate myself.

Getting Fired From My First Job!

I got fired from my first job and I’ve never been happier in my entire life. It took me +12 months to find that job, and I lasted less than 2 months in that role. I was fired because I clashed with an executive at the company and argued my way out of the job – I don’t regret that and I never will!

There are few experiences that will teach me as much as being fired like I was will. By being fired, it allowed me to reflect in a way I couldn’t have while working the job. I saw first hand what poor leadership, emotionally immaturity, and incompetency looked like. I was brought in as a data analyst to look at data that was spread out in Salesforce and SQL tables, and was told to instruct the business on how to operate given this data. What ultimately happened is that I went to my boss with data and customer feedback, and it was my data/customer feedback against their “intuition”. At a bad company run by fools, the managers “intuition” wins over customer feedback and objective data. I refused to stand down. I saw that what my manager was suggesting was to not deliver customers what they needed and instead do what was easiest for the manager, and what would get them the biggest bonus. I said no!

My job is not to please a manager or make them look good. My sole purpose at any company is to do what is best for the customer so that the company is in the best place to succeed. I add the caveat of “do that the company is in the best place succeed” because you cannot always do what is best for the customer. It might be best for the customer to send all of them $500 Amazon gift cards until you’re bankrupt but that wouldn’t enable the business to succeed. This dual pronged objective function with maximizing customer experiences alongside doing things that are sustainable for the business are what drive me. At no point do I go to my job and think “how can I make my boss feel good”. I don’t give a shit about my boss or the CEO or my co-workers in the sense that I’m not there to appease them at the cost of delivering the best experiences to paying customers. To be clear, I will do all that I can to make the people around me feel safe and productive that I work with. I’m not a tyrant that sells people down the river so I can achieve my own goals. Until the day I DIE I will do right by the people around me! The point I am making here is that if a CEO or co-worker says, “I really think…”, my reaction will always be “but what are our customers saying?, “what is the data saying?” When I say I don’t give a shit about these internal stakeholders, what I’m saying is I don’t give a shit about these stakeholders while we have customers screaming, begging, and crying to be heard and have products crated/amended/fixed/etc. I will respect, listen, and hear those around me, but at the end of the day if we have paying customers who are asking to be heard and have action taken, that is what I will always try to do. In this case with my job, leaders actively told me to ignore what customers needed. There wasn’t a strategic reason for this. It simply wasn’t something leaders wanted to worry about…

You can read as many books as you want, watch as many lectures as you want, but the experience I had are one of those things you truly have to experience to comprehend. This was my first job, my savings were closer to $0 than they were closer to a comfortable safety net, the job market was still in Corona virus mode which made it quite tough to find another job, and rationally, all signs point to “deal with your tyrannical boss and suck it up so you can build up your savings, work on professional skills, and wait for the job market to get better”. Of course, I didn’t go with the “rational” path forward.

What I experienced was very simple. I spent many hours listening to our customers: I had them talk me through what they were experiencing, what the pain points were, I asked questions that helped me understand the origination of these pain points and why these didn’t exist 5 years ago, I asked about how these pain points were affecting their ability to productive, I had them send me data from an old CRM system to quantify the dollar amount of their losses due to said pain points, I asked them what a “dream” world of no pain points would look like so I could understand what a near perfect product would need to achieve, I asked what they needed from me, and I succinctly and thoroughly documented what needed to happen to fix these problems that were leading to tens of millions of dollars of premium not being underwritten in the following years. My sole mission was to find a way to make sure these customers were going to have a solution that would help them, and ultimately help the business. The interesting dynamic in the insurance industry is that not all products are the same. You have home, auto, pet, flood, jewelry, commercial insurance, etc. All of these insurance products have their benefits and their downsides. The most attractive asset, at least in my opinion, is home insurance. Home insurance insures homes against a list of perils. Most customers are required to purchase home insurance given the money that was used to buy that home isn’t the customers – that money is the banks and is lent to the customer in the form of a mortgage. Most people have to have auto insurance (not in NH) but auto insurance is inferior to home – why? One of the most important metrics for a business to track is the lifetime value of a customer (LTV). All an LTV says is, what is the expected dollar amount we expect from a single customer for the rest of their relationship with our company? Of course this is a near impossible question to answer with a specific dollar figure, but the purpose of this number is to get a sense of what type of money customers are spending (are some purchasing big ticket items more than others?), how many customers are being churned through, and how loyal are customers to the business? The LTV for a home insurance product is going to have less renewal competition compared to auto because home insurance payments can be linked to the mortgage payments and mentally, customers figure they are paying their home for 30 years and there is less of a need to try and “shop” for better prices when this giant big ticket item has been settled and is being paid for. Auto insurance is as cutthroat as it gets with relatively low loyalty from customers. One year you may have a policy with Progressive, and the next year Geico, and the year after that State Farm. This lack of loyalty makes investors, executives, and managers wheezy when trying to forecast what auto LTV’s will be. The dream for a business is if you had someone purchase insurance from you and pay you the premium each month for 30 years and never file a claim to repair the item being insured (home, auto, boats, motorcycle, etc). What this dream scenario looks like on a balance is pure profit that costs (theoretically) $0 marketing dollars, $0 servicing dollars, $0 sales dollars (after the first year), etc. Due to the nature of the high dollar amount value of a home, the premiums are much higher than for pet or auto insurance, the customers are relatively more loyal, and the company that underwrites that policy and does a sufficiently good enough job to service that policy (if applicable) is looking at an extremely sexy business that is made up of high expected LTV customers who are likely to pay a stream of cash indefinitely that costs $0 to earn. Once the policy is written and customers are happy and not siphoned off by Geico or State Farm, you make near pure profit each year from that renewing policy!

I explained the unit economics of mortgage products because my customers/users dealt with the mortgage side of our business. These users deal with the most attractive business we can possibly write and I went to my manager armed with the data, the economic argument, and most importantly the feedback from our customers/users that they need specific help with our products to make more money and be more productive with their work. I went to my manager and articulated that we needed to find a way to address these issues so we can delight our customers and users and was told “that’s not my problem”. After an approximate 45 second response from my boss on a group call with 6 members, I said, “I respectfully disagree” and I was kicked off the group call and later fired that day after I told my boss that our customers were more important than their intuition (which has been wrong for 3 years and has led the board of directors to almost fire this person due to their lack of RESULTS – not doing what customers want and you wonder why you can’t hit your performance goals…).

You know, maybe I shouldn’t argue, maybe I shouldn’t be trying to push back against “the boss”, but if no one was carrying the voice of our customers to these cross functional meetings other than me, when would our customers have been heard? How bad would the business have had to fail before we realize, “crap we need to do something”? I don’t regret ferociously and tenaciously advocating for our customers and using their feedback and data to get my point across. If you are a manager and you don’t want your “intuition” (and ego) challenged by the customer feedback and data I gather I’m not the person to work for you. I’m here to make people happier, healthier, less stressed, work more efficiently, and the way I achieve this is by listening to customers and finding a way to take their feedback and integrate it into our products – at no point in this process am I looking to stroke an executives ego (or even my own).

If you want to have a bigger ego than level of customer satisfaction you deliver, your business will probably fail in the long run.

What does “VaLUe” mean?

One thing I’ve come across a lot is the notion of value. When you try to pitch a product idea to leaders you have to articulate its value; when you try to sell a finished product to a customer you have to pitch its value; when you talk about a company you talk about delivering returns to shareholders through generating value. As simple of a question as it is, I’ve been thinking a lot about value. What is it? How do you measure it – is it through $’s saved, net new $’s generated, time saved (which translates to $), is it through stress alleviated, etc? While the question of “what is value” sounds trivial, all of business revolves around the sustained delivery of value. If you don’t have anything of value you don’t have sales, you don’t have growth, and you won’t have a paycheck.

A quick search on the internet tells me that value means, “the regard that something is held to deserve; the importance, worth, or usefulness of something” and “Value is that quality of anything which renders it desirable or useful”. I hate these definitions. The reason I hate them is because it doesn’t help me answer my question. This definition reinforces the adage that something is worth what someone is willing to pay for it.

Value is something that is desired and useful to others. To me what’s important about value is understanding the market(s) you operate in. If you’re building software in healthcare versus consumer software, security and speed will be respectively important in both. When dealing with Protected Health Information (PHI) security is of the utmost importance. When dealing with your food order in a consumer software application like DoorDash or GrubHub security won’t be as important, speed of your order is what you’re going to be concerned with since your intention with using the app was convenience- obviously securing the data of users is a must, but the regulators, laws, and consequences that a company like United Healthcare and DoorDash would incur for mishandling data are drastically different. Mishandling the type of information that flows through these large businesses in the healthcare space could lead to jail time if PHI is breached and leaked due to blatant negligence.

The purpose of my above paragraph is to get across the idea that value differs between markets, businesses, and customers. What is valuable to a B2B SaaS company is going to be different than what is valuable to Lockheed Martin who makes equipment for the US military.

I always was skeptical of the product guru’s that spent so much time talking about “customer discovery” but the truth is, to understand what to build, what features you should prioritize, and how to build the most value revolves around what your target customers need. Different groups of people need and desire different things to different extents. Do 40 year old white women have the same willingness to pay as a 21 year old white man for a consumer software product? Most likely no. Their lives are different, their realities are different, they are looking for different things at their life and the products you build need to reflect their realities so you can capture their willingness to pay for a given product and/or service.

Like most things in life I think the answer to the question of “what is value?”, ultimately depends. Value is dependent on who your users and/or customers are. The reason value is different for each persona is because different personas each value different things. Most people might value the speed of a product or the security of a product, but if Tinder goes down the end of the world won’t come – if Amazon Web Services (AWS) goes down then the end of the world might actually come because how users interact with AWS is much more critical (military, healthcare systems, etc) than finding a drinking buddy on a social media app…

📸🎥Zoom Racism: Sneak Smart Racists and Haters 🚗🚙

When I started my new job a few days ago it was really interesting not knowing anyone in the calls I was invited to. I joined these calls without any idea of who did what, how senior each person was, or what people were really even talking about. All I really had available to me in these calls were the content of what people were saying (which I didn’t really understand), their tone, and their mood to try and decipher was was going on. In these calls I noticed that the way in which people of color were talked to by a white person was drastically different than how a white person was talked to by a fellow white.

For example, if the person asking a question had a name like Vinod, Kumar, or Wei Lei, the tone that was used at them was much more brash, aggressive, and short tempered by a Karen or a Susan (the people in charge (the whites)). When Karen would answer a question to a Kumar the tone was one in which you could tell Susan looked down at Kumar – “did you get that yet?”, “are you listening?”, “actually no, before you tell me no lets make sure we actually understand what you’re talking about”. The responses made me think there was doubt and questions around the persons intellectual capacity.

But when a Bill, a Dan, a Margaret would challenge Karen, the tone was night and day different. “Well gee I’m not sure Bill let me take a look into that”, “I might be wrong lets double check on that”, “that is a good point”. I’m not really sure what to do with this observation. I know there is racial tension at the place I work. It’s not the deep south racism where a person of color is called a slur to their face, this is the complex, sneaky racism that isn’t easy to prove -especially to HR. These people are sneaky smart racists. They know how to clearly show they think people of color are inferior, but they do it in such a way where you can’t really make a case against them by making comments that are technically not reportable, but what they’re expressing is clearly disdain, dislike, and disgust towards those that are brown.

Being the new guy, what do I do? Do I call Karen out in a 15 person call where 10/15 people aren’t listening and all they hear is me being the asshole (and they miss the edgy, racist, aggressive comments Karen was making)? If I were the boss it would be easy. I just tell Karen she’s a degenerate piece of fuck and it’s her last day. It may be harsh to say what I said, but there is also no place or time to treat people inferior in the way in which I’ve described above. Giving a pass to fellow whites, just to crack down on brown people, challenge, them, ask more fellow up questions, trying to undermine them, etc, needs to be eradicated.

The problem with smart racists, bullies, a-holes, etc, is that they are smart enough to not show their hate to the point where it can be used against them. An educated, racist family won’t tell their kids X race is bad, they will just say, “yeah we don’t play with them“.

I went to school with a black man from the deep south in MA and he told me he liked the racists in the south more than anywhere else. I was a bit puzzled when he said that but as I listened he told me that the racists in the northeast were secretive and it wasn’t clear who would turn on you and stab you in the back since everyone “seemed” nice. He said [racists in the South will tell you to your face they don’t like you and there is no ambiguity – you know who to stay away from. In the North you don’t know who is genuine and who is fake since people are smart enough to act least act like they are decent people] – what a miserable situation to be in!

My belief is that most people are smart enough to know they can’t just use a racial slur and make it clear they they less of brown and/or black people. If most people are smart, and their racism is subtle, what should you do? Do you ignore them and act as if you aren’t picking up on subtle actions, gestures, remarks, etc, that are never acceptable for a team dynamic? Do you call this person out when their actions are highly subjective and when they’re able to deny everything and turn things on you? It’s really easy to hold someone accountable when they come out and say a racial slur verbatim – but what do you do in the gray area where the perceived racist person can use their own educated ambiguity to protect themselves and turn your accusatorial behavior on you?

If you’re the boss you just tell those people to fuck off and beat it. If you’re not the boss, it isn’t clear. Maybe I’ll come back to this when I have a better idea of how to best handle the sneaky smart racists.

Reflecting on a Former Employer: Lessons Learned, How to Identify Land Mines, Operating Deep Inside of North Korea (or the SaaS equivalent)…

Imagine this:

Graduating college with a degree in Economics and Mathematics

Prior internships on Wall Street and Silicon Valley

3x All American Athlete

Dozens upon DOZENS of referrals to FANG and FANG-like companies

and amidst all of that it takes you thousands of applications (with a T) to get a job out of school.

Now think about this, if you’re in a job market that has been affected by Corona: millions of people displaced and now in the labor market looking for a job (a MASSIVE increase to the demand for jobs), fewer and fewer roles are open due to financial uncertainty and uncertainty as to how bad COVID will get and when a vaccine is created (a HUGE decrease in the supply of jobs), what does this mean for a new graduate? In pure economic terms, when the demand curve goes up and the supply shifts leftward (notating a decrease), it becomes hard as shit to find a job – yes, “hard as shit” is the correct economic language to understand shifts in supply and demand curves.

Now ask yourself this, let’s assume a college grad actually finds an employer to work for in these conditions after thousands of applications, how “quality” is this employer likely to be? Correct, they were absolutely dog shit, sketchy, morally questionable, treated their people like shit, paid like shit, and made their people feel like slaves for a paycheck! That was the morale of the story for me searching for a job during Corona – the sketchiest, shadiest, and most shit people were hiring. Think about it, the crème of the crop like Google and Amazon have THOUSANDS of people to pick from, why would they pick a non engineer from that pool that has no working experience and is risk to train and onboard? They wouldn’t! Instead I bounced around to a total of 3 jobs in the pandemic era.

The story of the first company has pretty much already been addressed: mediocre company, low pay, shitty management with little integrity and emotional maturity and it was the best I could manage given the economic conditions. After a few months at that place I was fired for telling my boss he was a disappointments to senior leaders and human beings (harsh yes, but trust me, I was not wrong to say what I said… in a few years that company won’t be around and that boss will terrorize dozens of more poor, innocent, folks).

After the first company I moved to another company. With the first job, I was able to work from home with my parents. What this means other than I was a loser, was that I didn’t have to pay rent! Financially it was a pretty sweet position. Despite making a very small amount of money for a “tech” company the way my budget worked out was nice. With this next job I ended up interviewing with the head of product, the head of tech, the head of product again, and I had an offer at the end of two weeks that was an increase of $35,000 from my last role. The only caveat was, I had to move halfway across the country and take on new bills: rent, car, car insurance, utilities, cable, internet, etc. The critical, and I do mean critical, mistake I made was moving from my parents home to their state too early. I was such an eager beaver to move from home and start the “Adult” thing that I didn’t take my employer up on their offer of taking the full 60-90 days to move out. Had I stayed at home, saved money (since I was not paying rent, car payment, car insurance, etc), I could have had ~$15,000 in my savings account before I moved. Instead of doing the most prudent and responsible thing that was save and wait, I moved out as fast as possible with as little savings as possible. Amidst all of the craziness that happened during Corona, for me, moving out too early was definitely my number one regret. There was no way to tell the future and predict I was going to get royally shit mixed by a scum company but it is what it is I suppose.

Going from South Korea to North Korea

When you work at a really scummy company where your old boss used to degrade and make fun of people that had high school degrees, you are really optimistic that you move to an environment where you can do your best work and help your team and company grow. At first, that is exactly what I was being told – that I would be able to ask questions, “challenge the status quo”, and build the best software products for customers which would ultimately help the business the most. Well, how stupid was I to think that all businesses are there to generate great results for their investors and their employees; I was about to ride a roller coaster that had a not so high high, and a royal shit mixing low. In layman’s terms, what that means is, I went in thinking I was living in luxurious, modern, and forward thinking South Korea, but in reality, I was living under the supreme leader’s brainwashing in North Korea all along! Let me explain (how I got shit mixed)….

The Beginning of the Shit Mixing in the Supreme Leader’s Hermit Kingdom

When you get your shit mixed, multiple! times, it’s hard to pinpoint exactly what the moment was when you realized you weren’t working in SK, but actually inside of Pyongyang. In order to dissect where things with awry, I made a list of “red flags” that capture different experiences that helped me realize I really might be in an environment that isn’t as great as I was told in my interview:

Red Flag #1: No engineers (as promised)

My shit mixing starts with deceit and lies. When I was interviewing for my role I was told that I would be coming into an organization that has “Empowered Product Teams”. These teams would collectively solution together and wouldn’t allow “stakeholders” to determine what gets built. This opposes Waterfall Development just as much as you possibly could. Instead of starting at the top, with Empowered Product Teams you start at the bottom with the engineers, product people, and others on the product team that actually are responcible for shipping the solution.

When I heard this I was levitating. This was my 21st century manifest destiny where I believed that under this empowered model, I was destined to produce great work. My thinking was, if I got to work with highly intelligent people who were all equally driven to create tremendously valuable and elegant solutions for customers, my team would kick ass! Well, that was all theory and all in my head because my team didn’t exist when I signed the offer letter.

I was told in my interview I would have a product team and we would be building solutions but what I wasn’t told is that it would take months to hire them all. That is where the first red flag comes in. I land halfway across the country, I start my first day, and am told that I need to “onboard”, but as a few weeks pass and the as the legitimate excuse of onboarding as a time consumer wore away, I asked where my team was. It turns out, the software engineers, the product marketer, and the designer that would sit on my team hadn’t been hired. This was strange to me considering I was told I would join the company and they would be there… Given the company was a startup, you don’t sit there an complain and whine, you find a way to be productive and that is exactly what I did (just without an engineering resources).

Red Flag #2: Ignorant, Stubborn, and Low Intelligence CXO (intentionally not defining what their role was)

Again, much of what I write about is prefaced with [I don’t know too much given I have so little experience in the working world], and perhaps that is applicable here, but it didn’t take me long to figure out about one of my senior leaders. The notion that we should respect our elders because they are old is absolutely stupid to me. You should respect people because A) they are humans and all humans deserve some level of basic respect, and B) because they have earned your respect and have shown you they are worth respecting. If you are old I will respect you simply because you are human, but just because you have gray hair and wrinkles doesn’t mean I’m going to act like your word is that of God. The same is true to me with a senior leader. Yes I’m going to treat you with respect because you’re a human, and yes in some way you write my paycheck, but I’m not going to turn to a mindless suck up that assumes everything you say is right – shit, the reason I was hired was because I’m supposed to challenge them and come up with more value than they could in by themselves.

When I started to engage more with this particular senior leader, a leader that had a lot of sway in what I did day to day, I started to unpeel the onion and realize a few things about this person. Firstly, this person was not fit for the job. Their background for the past few decades had little to do with what they were responsible for in their current role. Since this was a hyper-scaling company where tens of millions of dollars of value were being added to the company every few months, you would hope that this leader would know how to do what they were hired to do – it turned out, they were grossly ineffective: they could not hire, they could not strategically plan, they could not evangelize ideas to get others excited, they added a toxic amount of politics into the work culture where they protected their people like babies and squandered others who didn’t identify as one of their direct reports, and they could not effectively communicate.

I understand that people are flawed. Steve Jobs as an example was a real a-hole in many ways when you look at what co-workers said about him, but he was still effective. This person at my old company was an a-hole and not effective at all. In their tenure they could not point to more than one thing that generated non-trivial revenue in over a 12 month span.

Whenever there were intellectually complex conversations with this person they cracked. They were not able to follow, their responses had nothing to do with the preceding logic, and it was clear to see they were all talk with little to no critical thinking capacity. I don’t mind if someone is neurologically challenged at all – what I do mind are people that are neurologically challenged and then try to claim other people are “toxic”, “ineffective”, etc. The core red flag was that this senior leader had immense control over me – and would ultimately make the decision to fire me – yet they were hypocritical, they weren’t focused on creating value for users and shareholders, and they created an unhealthy amount of politics that ultimately created a culture where their people were invincible and could never be wrong. This was one of the biggest red flags when I saw that one of the most powerful people at the company was poorly educated, extremely poor at communicating, had little to no track record of generating business value, created immense politics, and was terribly ignorant and could not reflect that they were causing any form of issues.

The lesson learned here is, when you’re the boss you can do whatever the fuck you want and fire anyone and everyone that opposes you.

Red Flag #3: Engineers Were Never Wrong and the PM’s (and everyone else) was Always Wrong

One of the issues is that a technical senior leader loved Jocko Willink’s Extreme Ownership that highlights the importance of taking ownership of what you’re doing and asking yourself what you could have done better before you turn to others and allocate blame. While I appreciate the idea of what Willink is writing on, what I don’t appreciate is unequal application of the principle to different people at the company. For example, Product Managers by nature have to be fantastic communicators; if you don’t communicate what your customers need and what will help the venture succeed, it’s unlikely you will get buy in and you won’t be able to lead without authority. While PM’s do absolutely have to communicate clearly, this was taken to an extreme by a technical leader at the company. In their mind, engineers were never at fault. If an engineer did not respond to a message it’s because the PM didn’t communicate clearly. Even if the message was communicated explicitly clear via Slack, if an engineer didn’t respond, the technical leader would tell the PM their “relationships are weak and they are the issue for not getting a response”. While there may be grains of truth to the technical leaders point(s), there is still no excuse for engineers not responding to questions about their work for any reason. Whether you love a PM, hate them, or want them blown up with tons of TNT, you owe it to your team, to the PM, and to the company to communicate and build the value you were hired to build.

Slowly overtime it became clear that engineers had this cloak of invincibility where no matter what they did, it was never their fault. If they were late to work, didn’t do their work, didn’t collaborate (which part of the culture of the company was you had to collaborate) somehow, someway, a product manager was blamed for this. If an engineer didn’t do their work it was because the product manager didn’t clearly define what needed to be built. Ignore the fact the engineers signed off that they understand what was asked in the stories they committed to build, it always was someone else’s fault.

All of this was truly ironic. You had a technical leader preaching the idea of extreme ownership, yet technical members of the company got to blame everyone else (and not take extreme ownership) – how crazy is that? But to me, this was just the canary in the coalmine. What all of this indicated was more of “Red Flag #2: Ignorant, Stubborn, and Low Intelligence CXO (intentionally not defining what their role was)”. This leader was someone who preached a lot, but wasn’t consistent, didn’t apply the rules equal to people, had favorites, and

Red Flag #4: The Inability to Define What is Expected from a PM

It was not clear what was expected of me as a product manager at this company. I tried, and it was useless to go online and try to understand what a product manager should be doing. I looked at what the Silicon Valley Product Group defined as what a product manager should be doing, I looked at articles from Harvard Business School professors, I looked at former Microsoft PM’s define what a product manager should be doing, and despite all of these technicalities, it wasn’t clear how I needed to work at this company because this company was sipping the Marty Cagan Kool Aid of Inspired and Empowered. Simply all this means is that Marty Cagan puts forward a theory behind how product managers and how product teams should work. The main ideas are that a product team is comprised – at least – of a product manager, a product designer, and a technical lead. These three work collaboratively to come up with solutions that will generate tremendous value to their users. The next big idea behind this model is product discovery and delivery. You work collectively to discover what needs to be built and you work together to deliver what needs to be built to deliver the most value to the end users and customers.

In theory this sounds pretty straightforward: be a teammate, work together, have intellectually challenging conversations, agree on what delivers the most value with empirical data to users, and conquer the world! The issue at my old company was, we didn’t follow the Empowered model, we followed “our own model” that deviated from theirs. What that means is that we cherrypicked a few of the ideas we liked from Marty Cagan’s model, and by we I mean senior leaders in tech and product, and we applied those how leaders saw fit. In a world in which there is clear and thorough communication, this is no problem at all. What ultimately ended up happening was that it was unclear what model we were following exactly. In the book Empowered the recipe for how these teams should operate was spelled out clearly. But what happens when you deviate from the recipe and you trade out vanilla extract for maple syrup and beef for veef and basil for nutmeg? And what happens when these deviations are made and decided upon by senior leaders and it isn’t clearly communicated to the teams that will use it? You get ambiguity, confusion, and uncertainty over what everyone’s roles are and the ways in which we work together.

When we asked our senior leader what was expected from teams: was it products that hit financial goals, products that got delivered “fast”, etc, we were told, “Work collaboratively! We won’t have enough collaboration. COLLABORATE!” This is just like a politician screaming out glittering generalities that sound wonderful, but what do they really mean? What does “HOPE!” truly mean in terms of policies and legislation? What does collaboration mean when you’re in the thick of building software products? Does this mean we work together on the solution? If so, what is every individuals responsibility? Does the designer contribute design related ideas to the conversation? What if an engineer, who has virtually no experience with design, the customer, etc, wants to veto the designer? What does collaboration look like then?

The ultimate problem was that we had a leader that wanted to “collaborate” so much that they didn’t think about what collaboration really looked like. At a certain point when you are working on a team to produce value, everyone needs to come to the table having done their due diligence. If you want to disagree about why we should or shouldn’t have a feature, you need to do your homework and understand the customer, their problems, their needs, their pains, their day to day, etc. If you are a marketer, an engineer, a designer, hell even a product manager and you don’t truly understand the reality of the people you’re building a solution for, in what world should you have a voice in the conversation around user need? The core issue is that the demand for “collaboration” destroyed meritocracy. Instead of having the most informed people collaborating on a specific topic: QA testing, backend architecture, features to be included in the minimal viable product, marketing material, etc, our senior leader created a narrative that everyone on the team needed to have a voice for any given conversation – even in matters where their opinion was informed, they hadn’t done their homework, and when their voice would actually be a net negative for the team when you consider they haven’t done homework and are consuming time from the entire team.

What the hell do I know about QA testing, how sales will run their organization, how we want to structure the backend once the solution has been agreed on, etc? The reality is, I don’t know a lot about those things. While I could go and learn and try to be useful in those areas, I choose to rely on my subject matter experts in those areas to make the best decisions possible (assuming I have given them all the relevant information needed to make a decision that doesn’t run into any issues that could arise from knowledge gaps between a PM and the rest of the decision makers). I trust my team members. Yes collaboration is key to a high performing team and a high performing company, but there are extents to collaboration. The right people need to be making decisions. The people that need to be discussing QA testing for a spring need to be having that conversation, and importantly, the people that don’t add value, and even detract from that conversation, should not be in it. The issue with my team was that we had a leader that believed the only thing that mattered was to “collaborate” and ignored the fact that not everyone adds value in every conversation. The sensible person will understand that in some conversations you should remain silent simply because you don’t have the prerequisite knowledge that others have who are making the most informed decisions. But the issue arises when one of you leaders is jamming “collaboration” down your throat and you’re being told to collaborate or “there isn’t a place for you here at this company”. When you get threatened and think about losing your job due to not “collaborating” enough, you start to talk a lot – even when it’s not needed or appropriate.

The other part to this is idea of [not knowing what my role was] was when I blatantly asked one of the leaders and they said “be a humble leader!”. What exactly does this mean? Being a humble leader is more of an attribute than a job description. Lets say I am a humble leader, but with what? With prioritizing a backlog? With being the voice of the customer? With shipping software? With accepting software at the end of the sprint? The inability of my boss to clearly articulate what was expected of me was an issue in isolation, but part of the bigger issue came from the Product Marketing Manager (PMM). Both myself (the PM) and the PMM did not completely understand what our individual roles were. Yes we were on the same team, but what did we both need to do day to day? I am of the mindset that I will do whatever is needed for the team to succeed, but very quickly my PMM counterpart thought I was stepping on their toes trying to professionally undermine them. In reality, I just had no idea what was expected of me other than to “be a humble leader”. When you’re only told “be a humble leader” and the expectation is to build software that generates millions of dollars, you instinctively think, [I need to find a way to make a way to get things done]. Things progressively got worse when leaders in technology and marketing were not able to come to an understanding of who owned what between a PM and a PMM. My leader’s inability to communicate certainty didn’t help our team “collaborate”.

What I learned from this is that yes collaboration is mandatory for high performing teams, but so is trust. You have to trust that your teammates are making the best decisions possible in their respective fields where they hold specialized knowledge that you don’t have. Once you have communicated all relevant information to them to make the best decisions around design, algorithms, marketing, etc, you have to trust your team to make the best decisions possible without having a 10 person discussion on what to do when 7 of the 10 people know little to nothing about the decision being made. The last part of the learning is to make sure your team members know how each teammate is contributing to the end goal. If there is ambiguity of who is supposed to do what it leads to people stepping on toes, emotions flaring, and professional ego’s getting hurt, all every poor communication.

Red Flag #5: Product Managers Dropping Like Flies! (almost all PM’s were either fired or left in a 1 month time frame)

One indicator of the health of the business is how many of their people they can retain in some period of time. The logic goes, if you give your people the best offering, they have no reason to jump ship and go to a different company that can offer them a different role, responsibilities, better pay, flexibility (work from home, etc), benefits, etc. If you have high attrition, that is probably an indicator of something bad.

When I started at this company there were 7 product managers, when I was fired that number dwindled down to 2. What I didn’t realize at the time is that a mix of my fellow PM’s were fired and willingly choose to leave. Regardless of being fired or willingly choose to leave, the truth is, both are problematic. The people fired were being fired for political reasons – nothing to do with lack of performance or anything that dealt with being inappropriate in the workplace (sexism, racism, etc). The people that were fired – I am in this group – were fired for reasons that involved some form of politics and people with power and control not liking those under them.

The people that willingly left are intriguing to me. At the end of the day if you leave a company it’s often times because someone else was willing to treat you better: better pay, role, responsibilities, etc. The two PM’s that willingly left left for jobs that paid more and gave them more flexibility – a key indicator that your business is low tier. If people need only a few weeks to make such a monumental life decision, to jump ship and move halfway across the US to a new employer, your company wasn’t that impactful in their life! If your company was truly amazing it’s unlikely that nearly 1/3 of your product managers would leave within weeks of one another for independent reasons of one another.

The lesson I learned here that could be immensely beneficial is a lot of things are said out loud, and even fewer things are said out loud. One way to get a good sense of a business is to see what their employee attrition rate is. People talk with their feet and if a considerable chunk of the business is willingly leaving (and even being fired) something serious is brewing.

Red Flag #6: Everyone Got a Vote on the Product Team

I went into this slightly in Red Flag 4 but one of the nuanced issues I had with the structure of the team was that democracy was taken a bit too far. I do not believe everyone’s voices should be equal. There are times, in certain conversations where knowledge is needed to be valuable contributor, that will dictate who should get a voice and who should not. Should I get a voice in a conversation between QA testers where they have to figure something out for themselves so they can operate more efficiently as a trio? According to the senior leader that screamed “Collaborate!!!” the answer is actually yes, and that reality made the product team hard to maneuver.

My main qualm, and it really is a bit selfish but it would probably drive a lot of product managers crazy, is that engineers were trying to tell me what features needed to be in the product. I have no issue with an engineer, a designer, even a janitor offer their opinion in hopes of making the best products possible; what I’m not ok with are people are are offering their opinion – and especially contradicting a well informed person by saying “we shouldn’t do what you’re suggesting -without doing any form of homework to prepare and substantiate their perspective. I have no issue with people putting up ideas and collaborating. The thing that drives me insane is when people say no to me, or a team member that has communicated with users for hours, talked about what they need, what their pain points are, and for that contrarian who is uninformed to veto the group because of their own personal feeling.

If I’m going to advocate for a feature I’m going to have a list of 7 reasons why we should include it: based on customer feedback, based on enhancements to the UX, how it will positively impact our financials, etc. If you’re going to tell me no, I expect you to have as thorough of an objection. I don’t mind being told no, I don’t mind being told I’m a fat sack of shit that should kill them-self – as long as you get it out of your system and tell me why we should or shouldn’t do something related to the product and help me understand the logic and the reason you have the perspective you have I’m thick skinned enough and professional enough to see through the personal bullshit and collaborate with you to ensure we are delivering the most valuable product.

Because we were supposed to “collaborate” so much, it was not the product managers job to say what goes into the product, it was the collective team’s job to decide what we build. I really do not mind this idea of the team collectively working together to get to a solution but I do expect my team to put in some form of time investment to understand the market, the customer, the pains of our users, etc (Which by the way, all of these things were documents and shared with the team. The team even had links and regular updates on Slack to help them find resources to further their understanding that was needed to built products that would be valuable to customers). The problem was, and no one likes to admit this, objectively we had incredibly low quality employees at the company. It’s hard to say this without coming off in an erudite or conceded manner, but it was disappointing to me when I worked with people who wanted to do the bare minimum, didn’t respond to messages, didn’t take the time to look at anything I sent them, complained if they had to do anything more than the bare minimum, this list sadly goes on. I worked with maybe 1 or 2 people that I thought were high caliber; high caliber in the sense of urgency, professionalism, and the determination to produce great work. Most of the people I worked with had less than 3 years of professional working experience, a majority of the people didn’t go to a 4 year college, no one had advanced degrees like a masters or an MBA, no one had experience of success at prior companies – it felt like a team of people who didn’t really care if the work was being done. As long as they got paid and didn’t have to work past 5pm CT they were content.

To me, I don’t really care if you have a PhD, a GED, or can barely read and write. What I care deeply about is how you go about your life and your work. If you’re someone with a PhD that is taking shortcuts, treating people poorly, and moving without urgency, I personally think lowly of you. If you’re a lowly educated janitor that doesn’t take shortcuts, treats people fantastically well, and moves with urgency to do a great job, then I have tremendous respect for you. The way I view my coworkers has nothing to do with the education they have or how many credentials they have; what I care deeply about in my coworkers is if they want to produce fantastic work or not. If I’m working with people who don’t really care about the end outcome and don’t really care if we are building the most value for the end user, then I’m not going to get along with them and I’m not going to respect them because I value everyone’s time – including my own – and I want to make sure we are using the most of our time to yield the greatest outcome. If you are lagging, not giving a shit, and subsequently wasting my time with your lack of enthusiasm, motivation, and passion, don’t work with me – I want to produce the best work possible, not work in high school group projects where 8/9 of the people don’t care if it gets done.

The lesson learned here is, try to understand quickly the caliber of your coworkers. As someone who has struggled to gain experience due to Corona, many of the companies I have a shot at given I have practically no experience to stand by, are companies that attract mediocre people. I’m hoping overtime as I get more experience I can put myself in environments where people are highly motivated and don’t have a high school group project mindset.

Red Flag #7: Senior Engineering Leadership Could Not Hire Engineers (for 9 months!)

What is the role of senior leaders? I think one of the biggest things they are responsible for are hiring new people and retaining the people they have. When I kept hearing, “we are looking [for new engineers]”, over and over and over again, I knew something was up. In fact, much of what product as an organization was doing was entirely dependent upon engineering leaders hiring engineers. Product leaders and managers had laid out what we wanted to do in the next few years. We had a sense of where we wanted to go: expand the platform, use analytics to enhance the experience of customers, build out new products, etc. The only issue is, you can dream about all of these things and have all the “strategic planning” in the world, but if you don’t have engineers to work on these things they simply never happen.

For the first few months this inability to hire engineers negatively impacted me. I was brought on and told I would have a team, but in reality my team had not been hired and engineering leaders were making excuse after excuse as to why they couldn’t hire any engineers: [we don’t have any engineers in the immediate area – the area is tapped of Python developers], [we can’t find cultural fits], [we can’t find people that are willing to relocate to (a really not great part of the United States)], etc.

Here a few thoughts I have… Firstly, at the end of 9 months of trying to hire engineers, senior engineering leaders had a plethora of excuses as to why they could not hire engineers who knew Python, and that were willing to work in the office (so they could, you know, “collaborate”…). Keep in mind, at the start of this search these leaders imposed certain criteria that reduced the field of acceptable candidates by at least one order of magnitude: 1) the candidates have to be proficient in Python and 2) the candidates have to be willing to move to a dinky shit part of the United States (I.E. remote was not an option).

While two criteria may not sound like a lot, think about those in practical terms. If you don’t “know” Python you get cut. If you aren’t willing to relocate – which means moving to a part of the midwest that is really not attractive in any conceivable way when you consider Austin, Seattle, California, Raleigh, Miami, Atlanta, etc – you get cut from consideration. These criteria handicapped the company from being able to stay competitive in the labor market. Top talent by definition is highly sought after. When you are an employer and you go onto the job market offering extremely below market premiums, you ask those candidates to move to an area that is not attractive any any sense: from an angle of career development, socially, etc, you rule out nearly any chances of being able to hire top candidates that have the most experience. Now if you’re only able to attract medium to low tier talent, what happens when the company doesn’t really have anything special about it: no compelling vision or mission that could really motivate and inspire candidates and their altruistic side, no co workers or managers that have a lot of experience, patents, knowledge, etc? Just about anyone that has a great deal of experience and is considered middle of the pack talent won’t settle for a company that has nothing to differentiate itself from the others – keep in mind the pay for these roles was a joke too compared to other companies and their software engineering openings. So if the pay is extremely low, if the mission and vision of the company are non existent, if you’re being asked to move to one of the last places anyone wants to move to, and there is no one to really learn from at the company to advance yourself as a developer, why exactly would you take the bait and join a company like this?

Earlier in this post I talked about myself as a candidate and how I was only able to find really shady places to work when the demand for roles was high and the supply was low. The sketchiest opportunities emerge when candidates are desperate and the employers have the leverage. Now flip that – the candidates have the leverage and the employers are the desperate ones. What type of candidate will the employer find? That’s right, a desperate, most likely extremely unqualified, lousy candidate – or in the case of my company, they won’t find anyone at all!

Red Flag #8: “The Cool Kids Club”

Red Flag #9: Head of Product Got Executed

Red Flag #10: [I don’t care if you make money, I care if my engineers like you]

First Day on the Job (in literally 13 min from now)

After getting shit mixed in my first two roles I’m not sure what to think of this new role. I’m thinking about really only two things: 1) learning like crazy and 2) be a great teammate that gets things done for my team and company. I’m excited to start the new role and those are the two things I’m thinking about. Since this role is in a consultative landscape, and not me working directly for the company I’m building software for, I’m hoping there is a higher value and premium on producing and making things happen. I’m sure there will be politics like there is with all roles and companies but I’m optimistic that I’ll be working with adults that just want to get great work done in a professional setting.

Only time will tell. I’m optimistic regardless!

Learning to Build, Operate, and not be a Venture Douche

One of the things I’m really happy about in my career is that I’m pursuing the weeds and the actual details of products and services that need to get built to generate value. I’m getting close to engineers, I’m getting close to customers, their problems, feedback, and the actual building of solutions that run and grow businesses. A lot of people I know are going off into finance and are far removed from the actual value creation of the businesses they advise and raise capital for.

I see myself getting into venture capital at some point in my life and I’m tremendously happy that early on in my career I’m choosing to work outside of the investment space and work with the people building software solutions: engineers, designers, user researchers, marketers, fellow product managers and owners, stakeholders, etc. With that, I’ve thought about the question, what do I want to accomplish in the earlier part of my career when I’m an individual contributor who manages no one and is expected to come up with the solutions that generate value?

For me, I want to be able to spot a dysfunctional – or highly functional – product team and company. I want to be able to go into a business I’m either invested in or am considering investing in and understand the team dynamics and understand if the engineering managers and product leads are morons or not. That litmus test of idiocy comes from experience where you get to see the good, the bad, the ugly, and everything in between.

Another thing I want to be able to do is more quickly grasp who top performers and top talent are. The faster I can identify who the right people are to get shit done, the less time I’ll waste as a product minded person and as a future investor. When you start working everyone seems so knowledgeable and so fancy because they have 2 decades of “experience”. Truthfully, most people I’ve worked with – also at this point I haven’t been able to crack into a legit company that hire really smart people – are complete idiots. When you ask them about their logic or to think critically they break down. Most “senior leaders” I’ve come across so far are complete morons once you talk with them in detail and hear beyond their battle cries of growing the business and using the new company 401k plan they worked so bravely to create.

Whether it be understanding if teams are functional or not with my litmus test of competence I develop overtime as a product manager and owner, or whether it be figuring out who is legit and who is an idiot in a company, those factors all revolve around getting things done. I’m most excited in the early part of my career to take an idea, break down the features needed, chunk the work down into manageable pieces, build, get feedback, and iterate until we have something of true value. The actual building and generating value is what I’m most excited for and I think that will help me smear these investment banking kids that turned private equity that turned venture later in our careers.

The last thing I can think of when rattling off this post is to be able to spot the Kool-Aid, when people are sipping it, who is sipping it, and be able to crush it. What I mean by this is that people in general tell themselves lies. People lie about their appearance, their financial wellbeing, how their spouse looks (…), and in business, people lie about how great they are. Businesses that are in low standing tell themselves that what they’re doing is great when in reality they treat their people like trash and don’t add real value. Enron is a good example of a company that drank the Kool-Aid. Between the two most senior leaders at Enron – Jeff Skilling and Ken Lay, both of these men were convinced they were doing God’s work by deregulating the energy industry, yet after years of court hearings they were sentenced to a near total of half a decade in prison for how they misled consumers by manipulating their stock price through borderline illegal accounting practices. Not all cases will obviously be as pronounced as Enron, but I hope that as I continue working I will be able to see through people’s normalization of scummy behaviors. People that are scrum will try to normalize the way in which they do things, and when you confront them on what you believe is wrong, they will try to other you and make you look like you’re the odd man (or woman) out. What I’ve learned is that it’s generally hard to speak up to someone about bad things they are doing, and oftentimes you address a fundamentally bad person about the bad things they are doing, and those people are psychopathic and try to manipulate the situation to make you look bad. Colloquially the kids call this “gaslighting”. “Are you gaslighting me right now Ken Lay…?”

My reaction to Ken Lay gas lighting me

Part of the problem is that there are few people societally who 1) have the experience and are able to spot out shady practices and 2) have the personality to passionately and bravely call people out on what they are doing with confidence. I’m hoping with experience I can find best practices, learn from mistakes (both mine and others) and be in a position, that later on when the stakes are higher, I can squash the BS and the Kool-Aid with some amount of credibility and complete confidence.

My Understanding of Agile (specifically Scrum)

As a younger professional I’m new to business and how things are done. One thing I’ve come across in the world of software development are the different methodologies for getting things done: Scrum, XP, Agile, etc. What I’ve seen is all pretty common sense: engineers don’t like to talk to business people, business people don’t talk to engineers (unless there is a bug that’s keeping revenue from coming in), engineers are being forced to give estimates to business people that they can’t possibly come up with given they don’t know how long, or how hairy, an implementation might be, and most importantly, people are generally idiots who don’t know what they want until someone else has spent hours and hours grinding a solution out that they were told to build word by word (with the emails and documentation to prove it!).

My understanding of Agile is that people generally suck. People in general, whether they be engineers or business analysts or anyone in between, can’t read minds or perfectly state what users and customers need, and instead of trying to use a water fall method of defining everything up front, people have tried to find a way to produce software that isn’t as risky. When you define all features, specifications, functionality, use cases up front, and you give your engineering team(s) 5 months to build that document into fully functional software, you subject yourself to incredible risks. What happens in that 5 months if the market changes? What if new systems become the norm and your documentation didn’t plan for that? What happens if customers change their mind, or more likely see your work and say they want something close to that, but entirely different?

Scrum, a subset of Agile, accounts for, and recognizes the reality that these +5 month periods of development are too risk prone and that something else is needed. Scrum does this by introducing the idea of sprints which are timed periods that a team will develop software in. Some teams have sprints that last 2 weeks, some have 4 weeks, and other teams have completely different numbers. Every sprint – for this case let’s just assume a sprint is every 2 weeks – there are features that get selected by the Product Owner in something called the Product Backlog. These features that get selected to be built in the sprint are generally referred to as user stories. All a user story does is describe a feature that the team should build to deliver value to the user/customer. The Scrum team will convene during a sprint planning where the Product Owner will have prioritized the product backlog and will suggest to the team the most valuable stories to deliver to the business in the next sprint. In this meeting the team will take as many items from the backlog as the team’s velocity can support, and those stories will be taken from the Product Backlog and put into the Sprint Backlog. All the Sprint Backlog is, are a collection of the stories that the team has chosen to built during the next sprint. Each sprint the items in the Sprint Backlog, and the Product Backlog, will change depending on what is completed and what gets added and removed.

At a high level that is the general flow for how Scrum works: there are sprints, in those sprints user stories get assigned, those stories get estimates for how complex and how much time they will take, the team assigns story points to each story, and in theory, the most valuable stories get completed in that sprint and delivered to the business at the end of the 30 days subject to how much work the Scrum team can produce in that 30 days.

As I did my research, I learned that in the 80’s and 90’s there was a method called Waterfall Development where the people at the top of the business would say something gets built, the people under them would define what needs to get built, the people under them would architect it, and the people under them would build it. This method did not account for uncertainty – what happens if you don’t know exactly what needs to be built in the beginning? This method assumed that there were long development life cycles where teams could take months and even years to get something out the door. What has happened overtime is that these cycles have shrank due to the competition in the space, and uncertainty has risen given consumers don’t really know what they want – did anyone truly know that Vine and TikTok is what thirsty 15 year old boys needed? Absolutely not! Logically there needed to be some manner in which software could be developed in shorter windows where customer/user feedback could be looped in more frequently instead of at the end of a multi month development period.

Another thing I learned is that engineers in the past have gone a bit wild and have not necessarily aligned with what the business has needed. When I look into what the true role of a Product Owner is, it’s clear to me this person speaks for the business and is able to keep the team focused on what is truly valuable instead of what looks “cool” to a team of engineers. This almost sounds like a trivial task but when you have incredibly smart people who”think” something is “cool” and don’t have the context to validate if that multi week “cool” thing is productive, you need a product owner in the mix to make sure that everyone’s time and energy is being put into something that is truly important for the business and generates value. When valuable things are built, people get bonuses, admiration, respect, and generally the morale is exponentially higher in the workplace when the most valuable things are being built. Generally the opposite is true if things that are not valuable are being built.

To me Agile doesn’t seem that groundbreaking when you consider the flaws and shortcomings of the past. It feels like a natural evolution of eliminating unnecessary risk by getting feedback more often and by making sure that collaboration and working code is at the center of all that you do as a software development team.