There are two ways to get to Spenser Grayson's house from Amherst Regional Jr. High School. The most common is to drive down Rt 9, take a right from Echo Park townhouses, meander the long bend, pass the dump, and into the maple leafed wealthy sub-division of Amherst Woods. We took the other way.

But first, we took advantage of the hour his parents thought he was at baseball practice. We called 411 and pranked the information lady, shot pool with the Cambodian kids at the Boys and Girls Club, threw our mother’s paring knives into a tree, bought 89c liters of generic soda from Cumberland Farms and stole little plastic dinosaurs from the toy store we had only recently grown out of. Finally, when we had exhausted the options for 7th graders in our sleepy little college town, and having no money left, we started the trek down main street to the tracks.

The railways tracks went through the thick, mosquitoey pine woods. Young pine. Most of it scrubby and less than 30 years old - from the time in the 60s when the jobs moved to cities or other countries and there wasn’t any sense in being a small farmer anymore and the green menace of ivy and scrub took back its shape. We shouted and threw stones, talked about each other’s moms, recited beastie boy lyrics, and called each other words the world isn’t proud of and doesn’t say anymore. We had nothing better to do.

At some point, the track takes a hard right and comes into a big clearing with a small river. We got in position, waited for the train, and acted out the scene in Stand By Me where River Phoenix’s character dives off the bridge. But the river was really more of a stream, and the bridge was just a couple feet, and we didn’t have a change of clothes, so mostly we just landed in the dirt and collected the quarters that had been crushed by the 407 Mail.

If this sounds romantic and old-fashioned, then I’ve misrepresented myself. We didn’t set out to create a delinquent Norman Rockwell painting; It was just the best we could do. We weren’t better than today’s kids. We’d rather have been playing Nintendo, but the TV couldn’t be monopolized that long; and we only had two controllers between the four of us. We’d rather have been watching porn, but I only had access to the 2d pencil drawings in my Mom’s “The Art of Pleasure” sex handbook and the lingerie section of the K-Mart catalog. This was the kind of shit you did when you had to make up your own fun.

And it wasn’t entirely safe. The dude who ran the Boys and Girls Club, turned out to be a pedo (no big surprise there); Kazu got caught stealing from KMart; we once burnt down a shack. I have a kidney bean sized scar on my right thumb from messing around with an electric sander. My teeth are ravaged from Newport soda. But I have stories to tell you. None of them are on Instagram, and they never will be.

Now I have a 14 year old daughter. She has never balance beamed a railway track, nor jumped off a bridge. Our driver brings her from enrichment activity to tuitions to a healthy high protein-low carb snack. Her day is scheduled from 6:30AM to 5PM most days and then she has about 2 hours of studies. After that we used to do stuff, but now, since she got Instagram a year ago, she’s mostly in her room talking to her friends.

Friends.

Friends she spends her whole evening and sometimes night chatting or calling. It’s good. It’s why I allowed her to get Instagram - so she’d have friends. Everyone else is there. But I can’t help but wonder, how long would they go looking for her if she lost the internet? Would they, in their sentimental 40s, write stories like this about the time she shared that cringe Tik-Tok dance video and they laughed and compared it to their history teacher? I don’t know. But I’m guessing not.

And she’s not as lonely as before - in fact - she’s pretty popular, much more than I was. I just had those 3 friends. But 30 years later, I’ve still got them - at least some of them - and I can’t imagine making it through the last three decades without them. Even if we don’t talk much, I know I got someone who will show up and take my kid if I kick it, someone who will go check on my parents if they are ill and I’m not around, someone I can tell without fear, “I’m depressed.”

This type of secure connection, and the growth I’ve felt as a result of it, is so fundamental to what it is to be me, it’s hard to imagine that 1 in 3 kids now say they don’t even have any close friends.

note: This piece is inspired by reading The Anxious Generation. Part two contains some bits of data from the book on the impact of social media and phones on kids. One crazy thing: 20 years ago young people spent 2+hrs a day with friends, now it is 35min!

other note: this piece sat in my drafts for over a year. I don't know why. My kid is now 15, and has pretty good self-regulation around social media. Mostly this is from us constantly talking about it and her rolling her eyes at me.

This is part two of a two part essay on the lack of community and the ensuing mental health crisis caused by social media and ubiquitious devices (mobile mostly).  Part one is here.

The graph above is from Johnathan Haidt’s “The Anxious Generation”. The book claims that there was a “great rewiring” which occurred between 2010 and 2014 when the first generation of teenagers grew up with personal mobile devices and that this impact is clearly seen in mental health outcomes.

He attributes the lack of relationship building (amonst other things) as the main culprit for statistics such as:

• Depressive episodes amongst teenage girls is up 145%, boys, 161% (absolute number of girls is 5x boys though)
• Emergency room visits for girls self-harming is up 188%
• Anxiety diagnosis amongst college students is up 134%. From 10% of students being diagnosed, to 25% of US college students now having an anxiety diagnosis.

My initial (cynical) reaction was that these are correlative with greater mental health awareness and diagnosis, however that wouldn’t explain the self-harm and suicide rates increasing.

Haidt concedes that a certain percentage of the uptick is increased awareness and diagnosis, but there are several factors to suggest the tech “re-wiring” of culture is directly responsible, for instance:

• There is strong correlation between increased social media use and mental illness
• There is dose response (more usage correlated in a roughly linear fashion to more illness)
• Several cases of withdrawal symptoms and suicidal ideation when technology is removed

All social science is subject to confounding factors and subjectivity, but it feels right directionally as someone who grew up in the 80s and 90s without mobile phones or social media. One of the most telling statistics is that when you ask US teenagers if they wish social media had never been invented, the majority, say yes.

I’ve spoken to many people in the past year since I completed the book and three things have stood out:

• No one is surprised that this change is detrimental
• Everyone is underestimating the impact
• Most people are misunderstanding the cause

Isn't this like Nintendo in the 80s, TV in the 50s and radio in the 30s?

It's a bit different.  Here's why: generally everyone understands that social comparison causes anxiety, that social media and mobile phones are addictive and that people are increasingly living in a virtual world.

For girls this is mostly social media: filters, unrealistic beauty standards, mean girls and frenemies. For boys it is primarily online gaming and port addiction, withdrawal and a male anger born out loneliness and failure to launch. For everyone it is less exercise, less deep thinking and lower attention spans. Nothing I’ve said here is controversial or unknown.

But this begs an important question: Previous generations (such as Millennials and Gen-X) are addicted to the same things.  We are forever on our phones and PlayStations and what not, but the mental health impact seems to be much more benign.

What changed?

By some measures, Gen Z and Gen Alpha are better off than any generation before. They drink less, do less drugs, have less sex and fewer of them have to work. Teen pregnancies are way lower, as are STDs, and even broken bones. So then why are they so deeply, utterly unhappy?

Haidt gives us a lovely metaphor to explain this phenomenon: Anti-fragile systems.

In greenhouses, you can’t grow tall trees. Why? Because the roots of a tree grow strong enough to support it only when wind pushes the trunk around. Similarly, our social interactions with friends, crushes, teachers, bullies, store clerks, bosses, teammates and family members are our anti-fragile systems. Each time a kid plays in an unstructured, unsupervised (or lightly supervised) way, they are building decision making frameworks, they are learning resiliency, they are partaking in healthy comparisons which inform their evaluation of the real world and their place in it. It’s not always safe; there are playground scuffles, there are car accidents, there are broken hearts, consequences to risk taking – but this is where our emotional root structure develops. Roots which enable us to see ourselves in the two crucial dimensions of human self-esteem: connected and capable.

The Difference between Boys and Girls:

People develop self-esteem differently.  Haidt uses the terms Social Validation and Agency

• Social validation: Knowledge that you are known, included in and admired by a group
• Agency: Knowledge that you are skilled and capable.

While boys and girls value both of these attributes, Haidt claims that across cultures, there is preference towards social validation for girls and agency for boys as their primary means of developing self-esteem and comfort.

This is why boys gravitate towards online activities which make them feel capable such as video games, porn and gambling, where women focus on social media and messaging to make them feel connected and validated.

The problem is that if you asked someone what they were most proud of in life, they would probably not say how many likes a post got or what level they got to in a video game. These relationships are highly transactional, and the achievements transient. And so, the young person doesn’t have a strong basis of self-esteem or safety from which to explore the world leading towards greater mental illness.

What do do about it:

I am convinced that we are at a time similar to the 80s and 90s in America with smoking where we had realized the scale of the harm, but we are still relying on the perpetrators to self-regulate as opposed to taking more drastic measures.

What kind of measures? There are two things we need to acknowledge:

1. This is not purely a regulation problem – Like any addiction, it’s a cultural problem and it’s a medical problem.
2. It is not a personal choice, it’s a collective action problem. As a parent, I can restrict my daughter’s use of screens and social media, but doing so: Excludes her socially and culturally and will be pointless because social acceptance is a higher priority than doing what dad says is good for you.

To be successful in fighting back, we need to a multi-pronged approach:

1. Regulation. Social media companies should be help responsible financially for letting under-age users engage with their systems - especially if they are engaging in ways that endanger themselves or others. Addictive loops should be discouraged and some limits legally enforced. Meta and Google can absolutely tell the age of a user even if they lie about it based on interests, and they know exactly how they are manipulating them and for what gain.
2. School support. Schools should be default phone free and there should be active attempts to socialize and mix kids. This is the primary place where those roots are built in our society and if kids are on their lunch break looking at instagram, it's not going to happen.
3. Alternatives. We need spaces. Common spaces made for play. We need activities teens and pre-teens want to do which are physical and unstructured or lightly structured.

Anyway, that's all I got for now and what I take from the book. I highly recommend you read it.

This post is about a post-surgical (sinus) complication I had 10 days ago which landed me in the ER with a lot of blood loss and an emergency surgery.  I'm safe now and mostly recovered. I hope this story helps you in your life.

"I will not fear death when it comes." Have you ever thought that? Logically it makes sense. What is the point of fearing the inevitable? I will not mourn my own loss of life, nor will my consciousness exist to feel sadness for the gap I’ve left behind.

But fear is contagious.

I’d already been bleeding on and off for 4 hours. When I started bleeding again in the ER, I was gagging on blood, there was blood running down my chin from my nose, but I wasn’t afraid. I was frustrated my surgeon hadn’t come, but I knew I’d be alright. I was getting cold and shaking a little, but I knew that one can lose a lot of blood and survive. A junior doctor was there telling me I was safe because “I’m in the hospital” (Isn’t the hospital where most people die?).

When the nose pack overflowed for the 2nd time and the doc started yelling at her colleagues like a medical TV show, I saw in her eyes and heard in her voice a small doubt. “Relax, you will be fine” was partially said to me, but partially said to herself. When she spoke to the surgeon on the phone in Hindi assuming I couldn’t understand: “Aap aana padega abhi, artery se bleed ho rahi hai, bahut, rok nahi sakti hun” (You have to come, it’s a big arterial bleed, I can’t stop it), I knew there was a small, but non-zero chance this could be my last hour.

This is a very strange feeling, and one I’ve never had before. I’ve almost died because of car or motorcycle accident, a near fall, etc. but there was no time to think about the experience until after the fact.

What if you had an hour to live? What would you do with it?

Mostly I thought about my daughter, and the devastation of losing both her parents in a 2 year span at age 14. I worried about how it would mess her up psychologically. I then decided I had to believe she’d persevere - she had people. I thought about the practicalities of her life after me. I texted my laptop password to our close friends. I sent quick notes to my best friends and family. I asked my basketball friends who are well connected to try and get a senior doctor to see me faster at the hospital.

Practicalities completed, I waited, and I cried. I was afraid...

I was angry at myself for going back to work right after the last surgery, for being stressed, for staying up late, for meeting friends, for being careless. When the doctor arrived 30 min later, and they wheeled me towards the OT, all of the anxiety left my body. It had no use anymore, the doc was here, whatever happened now was up to his skill and my luck.

Suddenly, the fear went away... I did not pray or grasp to being alive. I was okay if I died. My daughter would be okay. Everyone would be okay, and I would have no regrets.

I realized for those 15min, that I have in fact lived a great life. For all the worrying, complaining and ruminating I do (and I do a lot of all 3)… my great life was right in front of me all the while: The people I’ve loved, the ones who loved me, the songs I sang, the dumb jokes, all the times I wrecked my kitchen making a feast, my cats knocking things off of tables, and coming to sit with me when I’m sick. All the times I made the game winner, the more times I blew it. But mostly the inside jokes with my daughter, seeing her enjoy a meal, learn a new lick on guitar, playing video games with me, watching people on the street, thinking the same thing and smiling at each other, the mutual feeling that someone in the world fully sees you and has got you.

All of that, is my life.

And I let it just happen, fixating on a botched project, a nasty colleague, an insecure boss, a souring relationship, a difficult family member, a betrayal of a friend, a bum knee, a little belly fat… I was “almost there” or “could have done better” or “nobody likes me” or “why am I such a fuck up”, “why can’t I just go to bed on time or do yoga”, “why haven’t I lived up to my potential?!”

That great life. It was right in front of me the whole time. And it shone a million times brighter than all the other stuff. And in that moment, it was so obvious. And maybe, it’s in front of you too.

(x-post from https://jacobsingh.substack.com/p/how-to-start-a-product-engineering)

As startups evolve, their org structures must evolve to match the evolving needs of the company. Cross-functional product teams give way to matrixed shared services teams w/ and eventually to internal product orgs aka “platform teams”. This article will specifically focus on best practices for building platform teams.

This post (like the rest of this blog) comes from coaching sessions I do with tech leaders. This week’s session was with Dhruv Baldawa of Paystack. If you’ve got a product engineering leadership question you’d like to bounce around with me, I do one free one every week for this newsletter. Just fill the form.

Subscribe to receive new posts weeklyish on product engineering leadership. No other emails. Max 4 a month.✓

Jumping in.

Background:

• Dhruv is a Principal Engineer at Paystack, the leading African payment gateway.
• The tech team is 100 people (out of 250 employees).
• He will soon be leading the newly formed platform group.

The question:

• How should we best structure the org at this scale for reliability and scalability (not just product features)?
• How can I create a technical strategy that aligns to the business strategy?
• What are best (and worst) practices for building a platform team?

Session details:

From a CTO/Tech org lens, I like to think of the startup journey in 4 broad phases:

1. The scramble: x-functional teams purely chasing Product Market Fit (PMF) with little regard to maintenance or architecture. Optimizes for speed by doing only a few things at once and throwing everyone at the problem. High degree of flexibility and generalization (few specialists).

1. Adult supervision: Strategic alignment becomes an issue, as does quality when we scale. We start hiring specialists (e.g. mobile, QA, data engineering, etc). These specialists often are a bottleneck because multiple teams use them. Teams depends a lot on each-other (poor architectural boundaries) and we add EMs, PMs, etc to manage this “resource utilization” and end up with a lot of planning meetings, often Scrum or something scrumish is instituted to ensure communication happens. [ Longer post about exactly this over at Sequoia Cap ]. People start coming to work just for free coffee.

1. Platform teams: The bureaucracy and slowness of the “Adult Supervision” phase becomes unbearable and the product teams never maintain systems or automate anything. Platform teams are created to remove dependence on experts (e.g. a platform team integrates an ETL tool, removing a bottleneck on data engineering). In essence, these are teams which are building products for the people who build products. We can call these products “capabilities" as seen below (partial list):

1. Independent business units: Even with automation and platform teams, the org gets too large for a single leader to manage and it starts hiving off into different business lines, separate P&L responsibility, etc.

Although this progression deserves a longer post in itself, I’m going to dig into phase 3 (platform teams).

Why platform teams?

Dhruv put the problem well, when he said:

“Everyone is milking the cow, but no one is feeding it or giving it water”

What he means is that the product teams are responsible for business outcomes (e.g. payments, shopping cart, administration, lending, etc).  But no one is responsible for any particular code base, least of all the generalized ones (such as an API gateway or a transaction database).  In addition, no one is responsible at all for non-functional requirements like scalability, security, reliability, etc.  The org wants to address this by forming a platform team.

He’s seen platform teams fail because they are out of touch with the teams they serve, or they are starved of influence / budget or they fail to make meaningful changes on any reasonable time frame so is curious to discover what the best practices are to avoid this.

Let’s dig into what platforms do and some best practices on how to run them.

The ideal platform team is a product team:

We defined earlier that platform teams are product teams which build products that help the actual product teams build things for customers. This is a gross generalization, but it’s a useful metaphor since it correlates with many things we know about why product teams go south.

Distribution is more important than product: Engineers have been complaining about poor debugging capabilities. The platform team comes in and integrates a log aggregation service and a request tracing and search tool. Amazing. Only problem is, the garbage log messages sprinkled across 20 microservices make it impossible to use. Now you need all those engineers who were clamoring for this capability to go through and audit all of their log messages. Where do you think this falls in the product backlog? Fucking nowhere, - that’s right.

A good platform team considers this and only attempts products they have broad support for politically (boss says so) or are easy to build grassroots support for through incremental progress.  Always consider distribution as the primary hindrance to success, not how useful or how easy it is to build something.

Connect the dots: When planning a “tech roadmap” or “engineering roadmap” as distinct from a “product roadmap”, it’s super important that you have some tangential connection to your company strategy. For instance, if your strategy is to be the “bank with the best customer service”, then investing in an automated ETL pipeline for customer data makes sense so your CRM team has up to date information. Sure, it also means the CRM team stops bugging your engineers, but you should be able to connect the dots for the CEO too and be defensible. Here’s a template which might help.

Priority is a singular noun: Many force multipliers in engineering don’t have any benefit unless you have 100% adoption. For instance, let’s say you want to use a more modern CI system which allows you to stage hotfixes and the old one doesn’t support it. This requires every single micro-service to update its Ansible/Puppet/k8s/whatever build file. If even one service isn’t done, then all this work adds no value. Teams will often give an arbitrary “20% to engineering work” as a concession. This is a terribly broken model, because 80% of the work is happening at low efficiency, and if the 20% isn’t crossing the finish line on a project, it’s just making the project take longer because of context switching and shifting baselines.

So when a project requires 100% compliance to be effective, get a mandate from above, stop everything (within reason) and just get the SOB done in a week. Trust me, nothing is that hard when everyone is mobbing it.

Build in the public, be a plumber coach: That being said… most projects do add value without getting 100% done. So most of the time, your job as a platform team is to be a janitor, not an architect. Staying in touch with deployments, on-calls, onboarding, migrations, etc and unblocking people is the primary work. When you’ve served them, only then will they listen to you as you try to push for new standards.

Keep weekly or bi-weekly demos / emails going out, run lunch and learns, facilitate post-mortems, and ensure engineering problems get the right visibility. This requires that you also understand the product roadmap and are willing to get your hands dirty with operational concerns too.

Rotate.  It’s crucially important that you don’t let people stay in product or platform teams forever.  Folks should be shifted around either on a rotational basis or longer-term.  That does not mean having one person half in either team, but perhaps doing a quarter in the platform team once a year or moving after a year in product makes sense.  The reverse is also true.  Failure to do this will ensure Conway’s law trips up your best laid plans.

The takeaway (1m):

Wrapping up and other ideas:

I hope this post has helped you think about how to structure your engineering platform teams. It’s a super interesting topic and I could have written another 2k words here. Specifically, I’d love to explore:

• Different execution models of platform projects
• Service design and domain boundaries in software architecture
• Framework and product release cycles and dependencies
• Education and inclusion of non-technical staff in platform team priorities.
• Design, product, analytics and other specialist platform teams.

If there’s anything you’d like to share on the above or additional questions you want to dig into, please leave a comment on twitter and/or fill out my weekly free coaching session form.

Most conflicts are between two well meaning people who love each other:

Usually there is a misunderstanding when one person says something that hurts they other unintentionally. The first reaction comes from a place of anger or feeling disrespected.

That reaction usually overstates the hurt, and comes in 3 forms:

1. Hurting back
2. accusing the offender of either intentionally doing it or
3. An attack on the offender's character.

Then the offender is shocked with the accusation and defends themselves, focusing on the offended person's response instead of the original thing.  They do this since to them the original offense wasn't intentional and isn't seen as even a big deal. This goes on forever if you let it.

Each thing said in response is like a new car pulling into an intersection. Eventually it's gridlock.  But each new argument adds a new car trying to pull though.  Now, the only way out is to reverse each car one by one by hearing the hurt feeling and acknowledging it (at least).  Someone has to go first. Unfortunately, the only available traffic cops are also the drunk drivers.

When I go first, say sorry, and back up my car, I expect you to do the same.  If you don't, and instead pull forward, I get pissed and drive mine back in the fray.  It's not about who is right, but there was offense taken, and that offense needs to be understood and acknowledged.  

You don't necessarily have to say you were wrong, but if I feel like you don't even know what I'm upset about, I feel like you don't even care, and if I feel like you don't even care, I'm not going to make two moves in a row.

This is how we can manage to stay in unproductive conflict with people we care about over things we don't.

The word agile is pretty frustrating.  Not because it's the wrong word, but because it's been so badly coopted it longer means anything.

At the heart of it, Agile software development is simply the practice of executing work in small batches, measuring the impact quickly, and then starting a new batch with that new information.  It is quite simply optimizing for learning.

One of the biggest mistakes organizations make as they scale is they try to optimize for utilization. That's a fancy way of saying "keeping everyone busy."

Why is this a bad thing?  Well, if everyone is busy, they cannot absorb any variance - the antithesis of agile.  

Imagine a highway with 4 lanes where every car is going exactly 70km/h and all cars are 3m apart.  This is optimum efficiency.  We are using all the space available and the maximum number of people are going the maximum speed.

What happens when someone needs to change lanes to get to their exit?

What about an accident?

What if someone is driving 50 in one lane?

This is why we need slack.  Traffic jams are not because there are too many cars - traffic jams are because there is variance, and not enough slack in the system to account for it.

This post is an explanation of why slack is crucial for agility and lastly a proposal (the Slacklog) as a way to build meaningful, intentional slack.

The Theory of Constraints

While Elon Musk is planning to turn all our cars into robots, and that's all well and good, it will be a long time before software companies pull off something similar.  So we have to deal with the issue of multiple individuals and teams pulling from the same dependencies.  Dependencies can be tools like "staging machine" or "database update" but they are more often people like "marketing department" or "QA tester" or "Front end engineer"

This brings up the central problem in manufacturing and in software development: The Theory of Constraints.  This post will make no attempt to explain it.  Go read "The Goal" or even "The Phoenix Project" or just "The wikipedia page" if you want more info.

Basic gist is: Your assembly line only moves as fast as the slowest part.  Optimizing anything else just makes things worse.

Not all projects are created equal

So back to optimizing for utilization. The tricky thing here is that in most organizations, there is one project which is 10x as important as all the other projects.  Not all things are worth optimizing for.  I love the google doodle team, but if they had a critical engineer who was required every time the search index needed to be updated, I think we all know what the right call would be.

But people are not fungible resources.  You can't just take them out of one project team and throw them in another.  There is a context switch, there is a skill mismatch, there is domain knowledge, there are relationships to rebuild.  So we have org structures and resourcing to ensure that the one most important project gets all the people it needs.

We assume the one thing is perfectly estimated and resourced and nothing will go wrong. But when something invariably does go wrong (merging on the highway or an accident), there is no space.  Everyone else is already fully utilized on other stuff. We try to adjust, but we just jam up the whole thing.

The case for slack

Now, many would say "that's okay, it will happen less efficiently, but it will happen eventually."  This might be okay for you.  But the core tenant of agile is rapid loops of small batch releases and learning. When the organization is running multiple projects in parallel instead of a few key projects serially, we will absolutely hit gridlock.

Add to that cross-incentives between different stakeholders, and it becomes unclear which project is the Google Search Index and which one is the Google Doodle.  Even if it is clear, the Google Doodle manager is measured on "awwws per minute" and will obviously resist giving away their key engineer.

Makes sense that we need slack in the system to allow for priorities to shift and mistakes to happen, right?  How do we make it happen?

The basics

You can't have slack all over the org. So first step is to resource fully dedicated x-functional teams to products and keep those boundaries fairly rigid.  There's a huge cost to "borrowing" engineers between products.

The second step is to correctly visualize and measure the value stream (where delays happen) so that it's obvious where the constraints are.  This could be as simple as a standup, or as complex as a Kanban board.

The third step is to limit specialization. In the Google Search Index team, let's say we have a database indexing engineer.  They may be 25% utilized most of the time, but during a big update, there might be demand for 400% of their time.  This slows the entire project while the rest of the team waits on them.  They move from being the slack to being the constraint.  A forward thinking manager would ensure that another engineering with similar skills (a background in caching or encryption) would x-train so they are able to do some of the indexing engineer's work.

But we can't just pay people to sit around!

Even if we do the above 3 steps, there is still a problem.  As a project starts, It's mostly product and design.  So engineers are at very low utilization.  They participate in the product and design work a bit, but are usually not even on the team at this point (another problem). QA is zero util.

Next phase we are mostly building out an MVP with a limited backend to test the market.  So all 3 front-ends are engaged, but backend work is light.  QA is planning a bit, but mostly empty. Then we engage QA at the end of an iteration, but they take 4 days to test the build while others are mostly sitting empty.

If product and other engineers do QA a bit and a front-end engineer learns some python, we can sort of balance this out (see above).  But it doesn't mean everyone is at 100% util.

So what happens on most teams?  

They start the next project on the roadmap simultaneously (this is the fatal mistake).  

If frontend is 100% utilized in sprint 1, and backend is 50% utilized, they will start the backend parts slated for sprint 2.  Sounds good in theory, but in reality, sprint 1 projects will spill over, demand will come from other teams for help, a new person needs onboarding, on on-call shift will turn into an all-nighter, etc. etc. In sprint 2, backend will again be under utilized as front-end catches up.

The slacklog

In my experience as a product engineering leader and a coach, I think the #1 reason teams fall into this trap is not that they believe doing more things at once is faster or better, it's because they are afraid of people sitting idle.

So here's a proposal:  Let's make a Slacklog for every team / function.

What's a Slacklog?

A Slacklog is a backlog of things which can happen, but don't need to happen.

Slacklog criteria:

1. Not in direct support of any quarterly business targets
2. Broken down to no more than 2 day projects
3. Immediately executable by >1 person on the team (no pet projects)
4. Easily understandable and clearly valuable
5. Uncontroversial (no politics or approvals)

Building a slacklog:

1. Get the team together
2. Use this set of prompts (or make up your own)

• We could avoid ________ on our team if only we had a tool that would _________.
• If we knew ______ about , it would help us prioritize.
• We think ___________ technology could make us do ___________ in a more __________ way.
• New joiners on our team find it hard to get started because of ____________.
• It would be much easier for people to interact with us if gave them the ability to ____________.
• We could make better prioritization decisions if we could visualize ______________.
• We would have less downtime if we fixed _______________.
• It would be easier to recover from bugs if we knew _________________.
• It would be a lot more fun to work here if we had ___________________.

3. Have everyone fill up minimum 1, max 3 ideas independently.
4. Group / De-duplicate.
5. Use dot voting to make a prioritized list.
6. Choose the top "team size / 2" problems. Have a pair of teammates work on detailing each (ideally put product people on some engineering problems and visa-versa). Note: this is not a commitment to do the work, see slacklog criteria #3 above.
7. If you need to play HiPPO, play a little HiPPO, but otherwise let the team own it.
8. Each pair diverges and creates 1-3 options on how to address the issue with a rough size.

• e.g. New joiners on our team find it hard to get started because of unclear and inconsistent API parameters. We could...
• Check all the inline API docs for correctness and explain inconsistencies (M)
• Build a facade around inconsistent services with Open API compliant methods (L)
• Make a simple training checklist and ensure newbies are run through it (S)

Now you've got a slacklog!

How to use a slacklog:

Purge: Ensure the slacklog doesn't get too long.  Consider wiping it out and building fresh every 6 months.  If something hasn't gotten done in 6 months, it's probably not very important.

Celebrate: Even though these are optional tasks, it doesn't mean they shouldn't be celebrated and demoed.  It's also important to make sure people doing the primary stream aren't the only ones being rewarded.

Handoff: Don't let people own tasks.  This is another form of constraint.  Tasks should be simple enough to transfer easily and should be jointly owned by as many people as possible.

Increase flow: Use this as an opportunity to have backend engineers do QA focused Slacklog items or designers do front-end engineering items.  They will be slower to execute, but in the future, they will be able to take on other job roles, thereby eliminating the need for slack.

Now go slack off!

I've never done this explicitly, but have tried similar things.  Would love to hear if it worked for your organization/team.

To all my friends who are still unvaccinated:

It is a personal choice, and I respect your freedom to make it.  And I still care about you.

However, there is also a public health consequence.  The R value for vaccinated people passing to vaccinated people is far below 1.  This means that even with breakthroughs, the virus will go away eventually if enough people get vaccinated.

Because you refuse to vaccinate, you will likely catch it, and the case will be worse, and you will be more likely to transmit it.  Each time a cell divides, there is a chance for mutation. So you catching it without a vaccine means a much stronger case, more cell growth, more chances.  If we play this game long enough, there will be a new variant which totally evades the vaccines.

But maybe it's not as big a deal as people say? Many non-vaccinated people in the US asked me if they thought the COVID death numbers were real - suggesting it was exaggerated by interests pushing an agenda.

I can tell you with certainty, the numbers are absolute fabrications. Governments are lying.

The numbers are much worse.

I was in India during the 2nd wave.  The government reported 450,000 deaths, but it's likely that *4 million people* died in 3 months.  For reference, the holocaust is estimated at 6MM deaths in 4 years.
Sources:
(https://cgdev.org/.../three-new-estimates-indias-all... - study, https://www.indiatoday.in/.../2nd-covid-wave-was-india... - news article).

It was horrible.  Delta ripped through and for a month, I don't think a day went by when one of my friends or colleagues didn't lose a parent.  There was a black market for everything.  Oxygen was $1k+ a day, people could not find wood to burn the dead in open parking lots because the crematoriums were full.

I sincerely encourage you to reevaluate your beliefs in light of the:

a). Very clear effectiveness of vaccines (see image) and

b). The very clear danger of this disease (especially the Delta variant).

Although he was not someone whose religious views I agree with, this quote from evangelist Desmond Ford is apropos:

"A wise man changes his mind sometimes, but a fool never. To change your mind is the best evidence you have one."

I don't trust governments or corporations.  But setting aside that concern, given the evidence, this is a question of how we want the next generation's lives to play out.  How many orphans is this world willing to absorb?  How many people will suddenly lose their parents at 50 or 60 years old without being able to say good bye?

Could vaccines have long term detrimental side effects?  Yes, absolutely.  No way to know for sure.  We have science which shows us it would be unlikely, but nothing 100% conclusive. This is a maybe.

Will Covid kill millions more if the global population is not vaccinated... at this point, it is a near certainty.  So please consider the choices and the risks and make a new decision.

Thank you

Being a leader, you are frequently privy to what people think about other people in your organization and related organizations.  This isn't a bad thing - it is part of being a safe space for your team.  But it can cloud your judgement.  And sometimes, the giver of the criticism asks you to, or you assume you should, go talk to the other party and try to change their behavior.  

In most cases you shouldn't and here's why:

Many believe the main issue with anonymous feedback is that the giver lacks accountability and so it won't be taken seriously.  But it is taken more seriously and causes another problem.

As social monkeys, our comfort (and performance) is highly dependent on feelings of social security.  The only thing worse than knowing everyone hates you is wondering if everyone hates you.

With anonymous feedback you know someone had a problem with your behavior but you don't know who or how much of an issue it really is. One person? Everyone? Someone who can harm your career?

But anonymous feedback also robs the giver of something important: perspective.  By creating a transaction as opposed to entering into a conversation, they are only expressing their side.  The are not understanding why the receiver behaved that way.

There may be good reasons for their behavior which the giver should consider, or there may be bad reasons that other people will have in the future and it is worth understanding them.

The giver in an anonymous format is also now susceptible to confirmation bias because they have not contextualized the receiver's experience.  Any hint of repeat behavior will immediately trigger the confirmation and increase the cycle of conflict.

In any request to change another, we are inadvertently changing ourselves.  Doing this without a conversation leaves us more susceptible to bias and conflict.

Given all of this, in organizations I run in the future, I will not encourage anonymous feedback and certainly will avoid at all costs being the relayer of such feedback.

Authenticity, candor and equanimity is a harder path, but for a sustaining culture, it's a path worth taking.

India recently launched vaccinations for people in the 18-45 age group.  Unfortunately, only a few centers are currently offering vaccines in this age group and they fill up fast.

The Co-win site currently has no way to filter only for sites catering to the younger age group.

So I created a simple Userscript (what is a user script?) which will simply hides all the 45+ slots.

To Install:

1. Install a userscript manager. For Chrome, tampermonkey is pretty popular.  If you need more info, here is a guide.

2. Download and install the script.

3. Reload Co-win and it should work.

People lower down the chain do not mind having direction set for them.  In fact it’s usually appreciated if it’s really clear.  What they don’t like is having goals set for them.  

What’s the difference? A direction is a problem to solve, a goal is a target to show that problem has been solved and probably some sense of the tactics to achieve it. It is a subtle difference, but an important one.

So, unless your entire org will get realigned to chase top level goals, it’s important that at the very least, we want ensure that each team is clear on which core problem they are trying to solve and if possible, have them solving only one.  And by team I don’t mean function (like Engineering), try to get it down to the “2 pizza” size if possible.  That for me is the goal of strategic planning.

The three phases of strategic planning

1. Identify an overall strategy given the environment and our position in it. Map that to a customer or org problem we are solving.
2. Make a mind map of the value provided to the customer, down to all unknown or un-executed pieces of that value
3. Apply that map to an org structure

When we are absolutely sure from the top that we are doing X, don’t make it a conversation.  Be clear on it, explain why, convince, etc… but it is what it is.  

Then form 2nd level x-functional groups for each major goal.  Their job is not to plan the entire 6 months of tactics.  Their goal at this point should be to define inputs: x1, x2, x3 whether it applies to their function of not.  “x” in this case is still in the realm of problems to solve, not tactics.  It doesn’t concern itself with the org and what is possible, it concerns itself with the customer we are trying to serve.  

In an effort to be inclusive, we tend to want to involve everyone early.  In the effort to efficient, we tend to involve everyone late.  Who is required to complete that map?  Not everyone who will execute on it actually, but people who are required to imagine the unknown / un-executed pieces.  

Post that, involve all teams to suggest goals for themselves which align to x1, x2, x3 and then try to consolidate the two and meet in the middle.  It’s a tricky dance for sure… but this is my orientation.

tldr; The first goal is to define smaller problem statements.  The next goal is to map that against the org. They are two separate problems.

This was a slack message in response to one of the young guys at work who asked

Wanted to ask does writing blogs about things help you with remembering details about those things and does it just gives you more clarity about what you had worked on ? Asking since,  lately i have worked on some interesting things but somehow i forget details. wondering if writing could help with this.

Writing is where I go when I have no choice.  When I keep repeating thoughts, when there is no way to untangle a mess.

People think good writing is about the words you use or the imagery you invoke. That's not really true.  That's pretty writing.  Pretty writing is pretty, but it's not always good.

Good writing is nothing more than clear thinking.  But clear thinking is really, really hard.  Writing, especially when edited (as opposed to just thinking or talking) let's you craft with confidence a connection between different ideas.

It forces you to explicitly define that connection, and why it is relevant so that another may understand it.   But the benefit is mostly your own.

So should you publish?  I publish about 1% of the shit I write.  Most pieces are hardly read, but I've found that I can't manufacture the pressure of public exposure, so I publish anyway to force myself to a higher standard.  In that, it's worth doing.

But also, some of my blog posts have gone viral and that's been good for my career, getting speaking engagements, etc. etc.

So yes, start writing.  I recommend the first thing to do is to make a time for journaling every week.  Shut off the internet, keep an hour to just document what went well last week, what you fucked up, why, how you will fix it and most importantly, what your intentions are for the week, and for life.

Sounds daunting, but it's just an hour. Even 20min is a good start.  This is one of the best practices I've picked up (even if I bail sometimes).

So good luck and just start.

Sometimes, I'm presented with a decision which seems pretty drastic, or affects a lot of people. When there is not a clear consensus on what to do, I try to look for the minimal possible change.

Minimal possible change, minimal time-frame to evaluate.
This means less disagreement around trying, and less impact to the team.

Choose a group responsible for the decision and the team empowers them to take the call.
This avoids the endless discussion which gets reset every time someone disagrees

Be specific about success criteria
Before starting the experiment, agree on what the concerns are, and how we will check in X weeks or Y months to ensure those concerns aren't a problem. This avoids confirmation bias when we typically continue to justify our initial opinions about what will happen.

For example:  Instead of "Hey team! I decided we will not have any more meetings between 10AM and 6PM on Mon-Wed", you could say:

"Let's try not scheduling any meetings on Wednesdays for one month.  It might be the case that this just pushes meetings outside work hours, so we will ask people not to schedule outside work hours, and will check in with people in 1:1s to find out if that's happening.  The decision will be revisited in one month by Amrita, Joe and Mariela."

If we do this, we can often spend less time in disagreement and more time learning about what works for us.  So next time you're thinking of what *really* needs to change that you can't seem to get everyone to agree on, try doing less, faster.