The End of Everything (Astrophysically Speaking) is, as the title makes clear, a book about endings. Specifically ours and the universes. But to tell the story of the ending it must, like all good books, start at the beginning. Katie Mack does a wonderful job outlining what scientists know about the Big Bang and how they know it. She then uses this as a jumping off point to expound on what this means for the various ways the universe might end, and how scientists know this.

Through clear language and a willingness to take short digressions she’s able to make the science clear and fascinating. She goes just deep enough to ensure she’s explaining the concepts she’s talking about, but she never goes so deep that it’s not accessible. Along the way she uses footnotes to great effect to expound on points, provide a side note, and inject humor. The humor is much appreciated and gives the book levity. This is especially appreciated because the book can be heavy readying as you think about the fact that she telling how literally everything will end and depending on your disposition might make you contemplate your own mortality.

Four primary potential ways of it all ending are covered – Big Crunch, Heat Death, Big Rip, Vacuum Decay. Each chapter builds on the previous as the scientific explanations for one possibility lead into the next. Along the way Katie Mack freely admits where science is currently ignorant. She covers the areas of controversies and where the math and observations don’t currently agree and how that is leading to further exploration. It’s a well done journey though the scientific process and how it builds over time.

A final possibility of the universe ending is included in a chapter called Bounce. This is where the book starts to falter a bit. In exploring this area the underlying theories come from different starting points than the primary chapters, so Katie Mack has to back track and try and cover some of these concepts in just a single chapter. This necessitates a shorter treatment that is harder to follow and doesn’t have the benefit of the build that the previous chapters benefits from. The content is still good, but it was a change that was harder to grasp and follow.

The final chapter of the book then looks forward to the upcoming research and the questions scientists are trying to answer to continue pushing forward. A lot of ground has been covered in the book and it leaves me looking forward to where science is taking us while giving me a deeper appreciation for all we’ve learned along the way. Even if the ultimate result is the end of everything.

If you enjoyed Katie Mack’s book and want to keep up with the latest goings on in science while not needing to read scientific papers, I’ve found Quanta Magazine to be an excellent source of accessible and well written articles.

The post can also be found on Goodreads.

I was asked a seemingly simple question recently: What does success look like as a manager?

On the surface there are as many answers as there are managers. Success is shipping the product. Success is hitting the team’s KPIs. Success is solving a deep technical problem. Success is nailing the roadmap. Success is increasing ARR. Success is solving the customer’s need. Success is fixing bugs. Success is clearing technical debt. Success is helping an engineer level up. Success is solving a process dependency problem. Success is …

All of these answers are fine and good. But I believe the question is missing a phrase, a phrase that changes the nature of the question and the nature of the answer.

What does success look like as a manager for you?

It’s now not about an outward definition of success, but is now instead entirely focused inward. How do you, as a manager, define success?

For me, the answer is both simple and complex. Simply, I’ve achieved success when the teams I manage hold themselves accountable.

What does it mean for a team to hold themselves accountable? Here is the complexity. It means that when there are disagreements, the team works them out without using me as an intermediary. It means when someone on the team deviates from team norms, the rest of the team will call them on it. It means when team norms aren’t clear, the team will surface the issue and work to clearly agree on them. It means the team will spontaneously retrospect and solve problems in the moment. These things are all part of the layers it takes for a team to hold themselves accountable.

Here is an illustration from one of my past teams. At standup one day, as the team was walking the board and talking over work, one of the engineers noted that several items had been sitting in review for a long time. This had been a persistent problem, but not one I as the manager was focusing on at the moment. This day, however, the team decided to solve it. They took a moment to talk over possible tools to help and settled on trying one that would send them reminders of open pull requests. Then they looked at process. They all agreed to ensure each of them set aside time during the day to do code review and what the expectation was for that code review. Did it mean running all the code and tests? Was it enough to just look over the code? etc. They agreed on the process, the tools, and then they agreed on the timeframe, committing to try it for a week.

The change worked great. Review began happening reliably and the team held themselves to it. This caused other ripple effects. Pull requests became smaller. The act of stacking pull requests where one pull request built on another pull request went away. Overall task size shrank. All because the team held themselves accountable.

A lot of pieces have to be in place for this to happen. You need a team that respects each other. They have to know it’s a safe space to speak up, to suggest ideas, to call each other out. They need confidence and comfort in the process, to know how it works, and how they can change it. None of this comes overnight, it builds over time. It took this team about nine months to get here.

My job as a manager is to create the environment where this can happen. It takes time. It takes persistence. It takes adapting to the individuals, to the team, and to the environment. In an industry where engineers are hopping jobs on average every eighteen months and companies are reorging just as often, this isn’t easy. But when it all comes together, it’s magical.

As a manager this is what success looks like for me. As a manager what does success look like for you?

—

This post was originally sent out as part of my newsletter, Learning Better Management By Sharing. Please sign up if you’d like to receive posts like this in your inbox. Thank you for reading.

Snark, noun
: An attitude or expression of mocking irreverence and sarcasm
• Merriam-Webster Dictionary

Even if you’ve spent very little time in tech, you’ve almost certainly heard snark. It is the lingua franca of tech. We use it to communicate and bond about shared frustrations, especially about the everlasting struggle to get our code and systems to just do what we want.

Except this is the good interpretation. It doesn’t take much for snark to turn dark. That sarcasm that can bond? It also carries with it an undertone of contempt. Contempt for the code and systems we work on. But we don’t stop there. We carry that contempt to the person who wrote that code, who helped create the system we struggle against.

There is a reason the unhealthiest teams use the most snark. They’ve lost respect for those around them. They’ve lost their empathy. The expression of their frustration is now expressed in a way to make themselves feel better by showing how they know better. They have stopped trying to understand how everything arrived at this point. They have stopped trying to understand how those who wrote the code or work with them operate under their own constraints and their own struggles.

Snark is a way of giving up. Snark says I know better, but I’m powerless, so I’m not going to try and make things better.

If your team has a lot of snark, they are sending a message. They are struggling and need help. It’s not easy, but it’s possible to dig out of this. The goal is not to drive out snark simply by forbidding it. That’ll just drive the snark to back channels. Instead question it. Ask: what frustration is this snark expressing? What is in this team’s control to change? Redirect the team or person to figure out what about their situation they can make better. Then start taking small steps to change it. For those things beyond the team’s control, explain why the system is the way it is. Explain the possible constraints others are operating under. Explain the history that has lead to this point. Explain a vision of a path out. Give context and direction. Give agency.

Agency is the enemy of snark. Once there is agency the focus is on using it, on making the situation better. Slowly the snark will fade. It won’t be easy. Habits don’t disappear over night. Continue using the snark as a signal, finding the change you control in it. With practice the team will start to find what they can control themselves. Eventually everyone will forget snark used to be the norm.

What if someone just won’t give it up? Everyone else has moved on, but they continue to engage in snark. They are isolating themselves, setting themselves up for misery. They’ve had the opportunity to learn and move on with the team. If they simply won’t go down the same path, you’ll likely need to let them go. Snark still pervades tech. It’s not dying out anytime soon. They’ll be able to find a place that accepts it, even welcomes it.

Snark is currently ingrained in tech, but it doesn’t have to be this way. Empathy, context, agency. These are the tools you have to eliminate snark. These are the tools that lay the foundation for a positive and healthy culture.

—

This post was originally sent out as part of my newsletter, Learning Better Management By Sharing. Please sign up if you’d like to receive posts like this in your inbox.