I love reading the latest blog posts from the Slack Engineering team, Will Larsen and the Stripe crew, and the fingers-crossed-occasional post-mortem on painful outages. They are a treasure both to observe how these teams are operating and because freely sharing knowledge and experience is rare today. I am jealous to have the experience of service migrations under the load of tens of thousands of daily active users, or even millions. It creates a whole new level of challenge.
But that is not where me and my team are today. Not yet at least. There is no doubt that having these teams as a guide post, as a north star to start moving towards. It is invaluable to have a list of known possible issues next to possible solutions to evaluate. No, we are still searching for market fit. That means we have different engineering challenges.
We have all heard of the seed-round startup asking themselves "Should we use k8s or not?" and chuckling to ourselves, knowing that its the wrong question. It shows that they don't know what is important yet.
Engineering in the time of Product Market fit is about being able to present something to your potential customers As Fast As Possible. There is one truth—No One Knows Anything. Your organization does not know what customers will buy. Having the answer to that is called Product Market Fit. You don't have it yet.
I've learned that the best mindset for working in this environment is to expect that you're going to delete, shelve, and entirely ignore most of what you're building right now. Because no one wants it. This is a tough concept for some engineers who treat their code like the precious ring. As the saying goes today for servers: cattle, not pets. So it goes for your code and your prototype designs, learn to let go.
Time is a finite resource and the two largest constraints on your time is money and attention. You have a limited amount of runway. You only have so many attempts at gaining your customers attention. You only get to make a first impression to a new customer once. The more and more missed attempts and your potential customers will start ignoring you because they think they know what you're about.
The challenge today is to find the sweet spot. Just enough tooling to make development just easy enough to turn around MVPs to put in front of your customers to test. Because some of your tooling will end up being ignored and unused. The most important thing is getting the MVP out ASAP. The more time you spend on tooling, the less time you're spending on the actual MVP. The more time you spend on future proofing the less time you're spending on MVP. Don't optimize, don't scale. Until the moment you have to. Make plans. Don't act on them. It is a test of willpower and focus.
These days I have a player-coach role. Operating at the Staff/Principal level, specifically at my current gig, means that a bunch of my time is spent ensuring that we are all working towards the same goal. I aim to leverage the work we've done in the past, and at the same time pick the next item to target in order to create a lever out of a time sink.
Throughout my career, I've been propelled by the endorphin kick of crossing things off the list and shipping features. Every day I could rely on replenishing some amount of energy spent. As an introvert that is incredibly important to me. Now, those moments are fewer are further between; however, when I do get those moments they are even sweeter. But I've learned there are two energies at play within myself.
Spending energy with my head down writing code does not sap my ability to turn around and help teams with my executive functions; problem solving, glue work, root causing, or planning the next moves. However, the reverse is not true. Spending most of my day on executive functions really does diminish the energy I have to put my head down and focus on coding.
There are great things about being a player-coach, but this one is unexpected. I would have assumed the energies worked in both directions—that coding would have tired me to executive functions, too. I count that as a win. I'm not sure that I will become "full" management, with no coding involved. But, I can't predict the future either!
Read more: Energy Levels
I started and ran a gym with some friends for six years. I learned a lot about training, and how to maintain and train without getting injured, and what to do when you do get injured. And we're not talking big "go to the hospital" injuries. Just the standard injuries when you are pushing your body past its current limits; strains, pulls, and alignment problems.
There is a common piece of advice that "When my knee hurts" the problem is not in my knee. The problem is actually in one of the adjacent joints: your ankle or your hip, and your knee is compensating. As a result of that compensation it is either over worked, beyond its designed range of motion, or out of alignment. And the "hurt" is your body's signal back to you to stop and adjust.
I like using this metaphor when diagnosing organizations as well. If you're putting your finger on a problem, or a part of your organization is crying out for help, it is likely that you need to look at one of the adjacent pieces of the org, the other teams that are interfacing. As we say in programming: garbage in, garbage out. If a team isn't getting the right inputs, or isn't working under the right conditions, or lacks context, their output isn't going to match your expectation. This is an alignment problem.
Alignment problems need to be solve from the outside. Because the part of the org looking for help either; does not have the capability as the org is designed, does not believe they have the authority, or doesn't know how, to fix the problem.
As a leader you have to answer the conundrum: who ought to have the authority and how can you make that a reality? How do you begin teaching others how to fix the problem they're dealing with?When do you change the organization to enable new capabilities? Without answering these questions you will continue to spend your time maintaining aligment. The only way to move on to different problems is to give someone else this problem.
Read more: A Diagnosis Metaphor
There is no shortage of discussion around how silos are harmful to people, teams, and whole organizations. Every level of humans is affected. I don't think I have to convince anyone there. However, there is a twist now—we are (for the most part) all remote. This is a natural breeding ground for silos to be born. Even when we are trying to avoid silos!
The common element to silos, handoffs, and asynchronous communication is: Context. Silos are bad because they purposefully deny shared context. This means you need a formal handoff. Handoffs fail when all the context is not passed along. "All the context" is why working asynchronously requires hard work and commitment by all parties.
Gone are the water cooler conversations, as well as looking over shoulders to help with a problem, and the quick nod on how something ought to work. Even under "normal" working conditions, handoffs fail. There is a reason you don't swap out a whole surgical team during a long procedure. You'd rather have the same someone on their feet for twelve hours because they have twelve hours of context in their mind. Think about that. As an organization, a hospital will forfeit "normal" schedules, 5-days a week, and adjust all their staffing and labor law compliance just to keep the same surgeon on their feet for 12+ hours, rather than swap a new person in after a few hours. They realize just how difficult it is to communicate a full context. They are doing one of the riskiest jobs there is—they have someone's life in their hands, their body open on the table.
Working asynchronously with people requires building that shared context over time. It is not going to come instantly. As an organization, you can support this process by keeping teams together for longer, with fewer distractions. The more remote, distributed, and spread out across time zones teams become, the more important it becomes for organizations to realize what is happening.
Two decades ago the only asynchronous work that happened in software was outsourcing. No one enjoyed trying to make it work. And it rarely worked. Companies blamed their international counterparts, but I bet the companies' inability to share the necessary context for asynchronous work was just as culpable, if not more so.
Read more: Silos are Bad, Handoffs Fail, Async Is Hard
I am sure the majority of managers in my industry would recognize Goodhart's law:
When a measure becomes a target, it ceases to be a good measure
What surprises me is how often this maxim gets forgotten! Whenever there are discussions about quantifying "How good are our estimates?", "Is our productivity increasing or decreasing?", or "Are our teams happy and healthy?" folks routinely believe that these questions can be targeted for improvement by (more or less) direct measurement.
Management routinely accepts that with humans "by observing something you change its behavior." They understand that the measurement will have some margin for error and believe "it is close enough." And they are probably correct. It is likely that it is close enough.
Once an engineer knows you're monitoring their productivity, and then you set productivity targets their ears start burning. Now they know that their next promotion relies on productivity improvement. They know their favorability within the org relies on productivity remaining the same. And, they know that if their productivity ever goes down they might get fired. And somehow management believes they will still have an honest measurement of productivity?
Managers have to realize that they cannot have their cake and eat it too. I believe this is a constraint when creating a well-functioning organization. If you're interested in quantifying these kinds of things, you can not also talk about "making estimates better" or "increasing productivity" . I truly believe once you do that the game is over, and slowly but surely you will lose the trust of your team.
If that isn't controversial enough for you try this one on for size. Common wisdom for increasing the productivity of your startup is to hire more people—rapid growth! I believe that is incorrect, it is only part of the story, at best.
Hiring people increases your potential capacity—not "real" capacity. Real capacity is how many things you can do at once. Potential capacity is about how many things you can do at once in the future. I think Will Larson illustrates the problems with rapid growth where you are always hiring more people:
Just how challenging this is depends on how quickly you can ramp engineers up to self-sufficient productivity, but if you're doubling every six months and it takes six to twelve months to ramp up, than you can quickly find a scenario in which untrained engineers increasingly outnumber trained engineers, and each trained engineer is devoting much of their time to training a couple of newer engineers.
In any scenario close to the one that Larson describes there is zero question that you've hired more people, and more people are able to do more things. But have you increased productivity, or have you decreased productivity? If you haven't put a considerable amount of effort into making onboarding effective, which is incredibly difficult, the chances are you will experience decreased productivity.
Odds are the executives told you: "Bigger, Better, Faster" and your response was: "Give me cash and I will hire people!" As a manager how are you going to manage this constraint? Eventually, people get trained, but what are you going to do until then, and how will you manage expectations with executive leadership?
Read more: Two Beliefs About Organizational Constraints