How are you measuring productivity? Consider the sheer combinatorial magnitude of skills and experiences at play. 10x productivity isn't an immutable characteristic of a person, no one can be a 10x better than everyone else across the board in every situation. Individual engineers don’t own software, teams own software. If you have services or software components that are owned by a single engineer, that person is a single point of failure. Build 10x engineering teams. The best engineering Orgs are the ones where normal engineers can do great work. Any asshole can build an Org where the most experienced, brilliant engineers in the world can build product and make progress; that is not hard. Most of us are pretty normal people. Great engineers are made, not born. Build socio-technical systems with normal people in mind. Shrink the interval between when you write the code and when the code goes live. Deploy time is the feedback loop at the heart of the development process. What is everybody's job becomes nobody's, assign owners. People do their best work when they feel a sense of belonging. An inclusive culture is one where everyone feels safe to ask questions, explore, and make mistakes; where everyone is held to the same high standard and given the support and encouragement they need to achieve their goals. The best engineering teams are ones where nobody is running on autopilot and where everyone is working on something that challenges them and pushes their boundaries. The only meaningful measure of productivity is impact to the business. Software engineering isn’t about writing lots of lines of code, it’s about solving business problems using technology. A great engineering Org is one where you don’t have to be one of the best engineers in the world to have a lot of impact. Nothing makes engineers happier than building things, solving problems, and making progress. People don’t belong to you, they may walk out the door at any moment and that has to be okay. Talent may be evenly distributed across populations but opportunity is not.
Charity MajorsIs micromanagement bad? As you get too far out of the details, you just become a bureaucrat. Use micromanagement for standard setting and demonstrating the caliber of thought, work, and effort that you want to see. Micromanagement is a shortcut that you don't want to always use. Leaders shouldn’t live in dashboards, look for data anomalies as a cue to micromanage. Don't be a micro-manager, be micro-interested in putting your users first. Good management is about more than setting clear goals and holding people accountable, truly great managers get deeply and personally involved in key decisions and help shape the outcomes. Micromanage your product on behalf of your users. If you stop being the most critical user of your product, you are toast. Treat micromanagement like a symptom and get to the root cause: lack of trust. In an autonomous workplace, employees are trusted to find solutions to the problems the founder hired them to solve. Before you give an opinion, ask yourself "Am I right or do I just have an opinion? If I am right, what’s the cost of being right?" and you might discover what you have to say is better off left unsaid. Trust others to do what they do best, focus on the things that only you can do and leave the rest to everyone else. Give and ask for feedbacks regularly. Give your team a box filled with ideas. Even if a lot of people want to be told what to do, they tend to apply their own approach to that order anyways. As a leader, it’s your job to be a storyteller. Hire managers who can do the work themselves. The managers you hire need to be capable of performing the tasks of those they manage. If they manage engineers, they need to be able to write excellent software. If they manage marketers, they need to be exceptional marketers themselves.
First RoundWhat is system design? System design is how you assemble services using servers, databases, caches, queues, proxies, etc. Good design is self-effacing, bad design is more impressive than good. A complex system reflects an absence of good design. Minimize the amount of stateful components in any system because stateful components can get into a bad state. You should be able to go through the database schema and get a rough idea of what the application is storing and why. If you expect your table to ever be more than a few rows, you should put indexes on it. If you need data from multiple tables, join them instead of making separate queries and stitching them together in-memory. Send as many read queries as you can to database replicas because the write node is already busy enough doing all the writes. Once a database gets overloaded, it gets slow which makes it more overloaded. Split out the minimum amount of work needed to do something useful for the user and do the rest of the work in the background. Background jobs should be your first choice for slow operations. A cache is a source of state; it can get weird data in it, or get out-of-sync with the actual truth, or cause mysterious bugs by serving stale data. You should never cache something without first making a serious effort to speed it up. An event hub is just a queue that shouldn't be overused. Events are good for when the code sending the event doesn’t necessarily care what the consumers do with the event, or when the events are high-volume and not particularly time-sensitive. When you need data to flow from one place to a lot of other places, the simplest option is to pull the whole data but you can choose to only push new data. Focus on the hot path; the part of the system that is most critically important and the part of the system that is going to handle the most data. Hot paths are important because they have fewer possible solutions than other design areas and go wrong more spectacularly. How do you know if you’ve got problems? Log unhappy paths aggressively. Think carefully about what happens when the system fails badly, retries are not a magic bullet. Good system design is not about clever tricks; it’s about knowing how to use boring, well-tested components in the right place.
Sean Goedecke