tag:blogger.com,1999:blog-82218869128766068282024-03-13T09:50:04.405-07:00Elided BranchesCamille Fournierhttp://www.blogger.com/profile/05090020862261633248noreply@blogger.comBlogger108125tag:blogger.com,1999:blog-8221886912876606828.post-9732838479329558202023-07-27T18:16:00.000-07:002023-07-27T18:16:10.306-07:00The Next Larger Context<section class="section section--body" name="b703"><div class="section-content"><div class="section-inner sectionLayout--insetColumn"><blockquote class="graf graf--blockquote graf--startsWithDoubleQuote" name="43b4">“Always design a thing by considering it in its next larger context — a chair in a room, a room in a house, a house in an environment, an environment in a city plan” — Eliel Saarinen</blockquote><p class="graf graf--p" name="a4a0">Frequently we will be given problems to solve by other people. Early in our career, these problems will usually be well-scoped and specific, eg:</p><ul class="postList"><li class="graf graf--li" name="71a0">Add this new data to an interface</li><li class="graf graf--li" name="671a">Make an endpoint that returns a certain specific calculation or piece of data.</li></ul><p class="graf graf--p" name="eea7">And as we grow as engineers these tasks become bigger but often the success criteria remains well-defined:</p><ul class="postList"><li class="graf graf--li" name="fb61">Write a service to manage the state of a customer.</li><li class="graf graf--li" name="6ee3">Create a new interface that allows developers to manage and track the status of their code change from review to deployment.</li></ul><p class="graf graf--p" name="ecb2">There are often plenty of decisions to be made in implementing these designs, but we are not identifying the problem to solve ourselves, just building the system to solve it well.</p><p class="graf graf--p" name="3dcc">A major challenge that I see many people hit right around the time they become senior engineers is that they want to progress farther in their career, but they expect that the way they can do that is that they will be given a hard problem to solve that can only be solved by the level of technical skill they’ve gained so far. In fact, they expect that the career path from senior engineer to even loftier heights (depending on your company that might be things like “staff engineer” or “principal engineer”) will go much as it has gone up through to senior: you’re given increasingly harder problems, and you get to use your skills to solve them.</p><p class="graf graf--p" name="291d">I didn’t write <a class="markup--anchor markup--p-anchor" data-href="https://amzn.to/3MuiUMA" href="https://amzn.to/3MuiUMA" rel="noopener" target="_blank">The Staff Engineer’s Path</a> because I’m not qualified to talk about a path I didn’t follow. But what I can tell you based on my years of managing people throughout the stages of their career and watching friends who are on the individual contributor path is this: it is exceedingly rare that the path past senior engineer comes from being handed increasingly hard problems. It’s not that there aren’t hard problems to be solved, for sure, but they are generally being solved by the people who were already around on the team when the problem was discovered. And most of us don’t work in research, so the job of exploring the edges of possibility and discovering completely new things is not part of what we’re expected to do. Instead, at the senior levels, we are expected to identify problems that match business opportunities with something that technology can solve.</p><p class="graf graf--p" name="ddcd">The blending of these two things, business opportunities and technology, is where you need to turn your eye, senior engineer. But that doesn’t mean you need to become a product manager, or a manager-manager, or even an expert in the business. Instead you should look at the problems you’ve been solving and that your team is solving, and follow Saarinen’s advice: look at them in the next larger context*. Here are some examples.</p><h3 style="text-align: left;"><strong class="markup--strong markup--p-strong">Current Context: A Bespoke Storage System</strong></h3><p class="graf graf--p" name="f90b">Let’s say that you are on a team that supports a bespoke storage system that has been built up over years for your company. You’ve been something of an expert in the internals of that system, how it works, how it scales, you have added some features to it, and you are capable of teaching other developers how to use it.</p><p class="graf graf--p" name="1da8">The next-biggest context to start to understand here is how this storage system supports the company that is using it. Why do you need a bespoke storage system? What are people putting into it? What are their complaints about the system? What are they using it for that surprises you? You need to understand not only the way the system works itself, but the way the people who are using the system interact with it. This gives you the larger context that it is operating in, and will help you see the next opportunities for this area. Is it time to bring in a new type of storage system, one that fits with some of the data your users are producing that isn’t being served well by the current system? You are supporting a bespoke storage system, in an era where companies are trying to move away from bespoke systems in favor of open source or cloud hosted solutions. What does this mean for the future of your system? How can you get ahead of that trend, either by showing true differentiation between what your company needs vs the external options, or by embracing that trend and drawing down the differences to allow the company to eventually move to one or more of the external options?</p><p class="graf graf--p" name="846d">The lesson from larger context here is that sometimes the advanced move is not to build a more complex thing, but to enable the company to embrace the broader trends in storage systems. But when the right thing is to build a bespoke solution, you will only do that well if you understand why you need to differentiate and how to make the case for that based on the understanding of the larger context around your system, namely, its users.</p><h3 style="text-align: left;"><strong class="markup--strong markup--p-strong">Current Context: An Inventory Management System</strong></h3><p class="graf graf--p" name="3599">Now let’s take a very business-focused example. Imagine that you are an engineer on an inventory management system. You have overseen the development of this system to account for the nuances of the company that uses it. You understand very well how the operations team thinks about inventory, how they plan to buy new things when inventory runs low, and the kinds of reports they want to see on a regular basis about all things inventory.</p><p class="graf graf--p" name="6f30">The next-biggest context here could be a few things. It could be the entire context of warehouse management. If your company not only tracks inventory but actually manages the warehouse they use to store inventory, they probably have some warehouse management systems that you have integrated with your inventory management system. How well do you understand that world? How does your inventory management system fit into it? Are there opportunities to build out better integrations that could provide more accurate reports for the operations team forecasting inventory needs?</p><p class="graf graf--p" name="acef">The other side of this information flow of course is the information that you’re getting from the customers themselves. You’re tracking customer behavior in some way, if you’re working in any sort of modern commerce company. Are you automatically feeding information about customer interest in your products into the inventory management system to improve planning? Or, can you use information about inventory management to show to customers which items are about to be sold out?</p><p class="graf graf--p" name="3622">These questions may sound like product questions, but in many cases they are all about technical challenges. Integrating all of these disparate systems together in an effective way is challenging. Even if all of these systems were developed in-house, they will have evolved at different rates and in different ways, and feeding new data from one system into another can sometimes require that you rethink the entire way the systems work together. If you built your inventory management system to do batch processing, for example, because you never expected that inventory would change fast enough to need real-time updates, you don’t have an easy way to feed information about low stock dynamically to the website. In fact, may websites fake statistics like the number of users buying a particular item because they have no easy way of feeding this information back and forth.</p><p class="graf graf--p" name="3679">You need to think about the larger context of your system both to identify business opportunities that it could be filling, but also to predict how the technology you’ve built to support the current needs might fail you if you needed to integrate with a new model.</p><h3 style="text-align: left;"><strong class="markup--strong markup--p-strong">Current Context: A Developer Tools Team</strong></h3><p class="graf graf--p" name="5443">Our last example puts you in the context of a team that supports the tools and processes other engineers in your company use to develop software. You are the person who supports Jenkins, and all of its various integrations, for doing build and test. You know Jenkins inside and out, and have created an impressive set of automation that makes it easy for you to manage a large number of build and test pipelines for the company. However, this project has only been around for a little while and many teams still don’t have good continuous integration processes.</p><p class="graf graf--p" name="55f1">The next-larger context here is one of education. How are people using your product? How many teams understand the power of the automation that a system like Jenkins can provide? Where are there additional places that can take advantage of this system? What would be the blockers for them taking advantage of the system?</p><p class="graf graf--p" name="866e">By teaching people how to use the system and getting more users into your system, you will start to understand the patterns of testing and integration more broadly at your company. You may identify pieces of support that are missing that would get more teams to be able to release more frequently, such as a good feature flagging system. You may identify that the artifacts you build are huge and take a long time to create, and this could lead you down a path of figuring out how to make those artifacts smaller or faster to build. You may simply identify the need to set up some kind of classes for new developers about how to write good unit and integration tests, so that they can get value from running their code through your pipelines.</p></div></div></section><section class="section section--body" name="861c"><div class="section-divider"><hr class="section-divider" /></div><div class="section-content"><div class="section-inner sectionLayout--insetColumn"><p class="graf graf--p" name="92e5">What all of these examples show is that, as engineers, when we are looking to do a larger project than the ones we’ve done before, we need to step out of the context that we normally operate in. When you look one context bigger, you will see immediate new opportunities that you can tackle in adjacent areas. So don’t wait for the next project to come to you, seek it out by looking at the slightly bigger picture. That is where you will find your growth.</p><p class="graf graf--p" name="e60e"><em class="markup--em markup--p-em">*You look only one context bigger because it is easy to overdo things and violate our “evolve complex systems from simple systems” principle when you try to go too broad.</em></p><p class="graf graf--p" name="ff05"><em class="markup--em markup--p-em">Enjoy this post? You might like my book, </em><a class="markup--anchor markup--p-anchor" data-href="http://amzn.to/2nw1QN5" href="http://amzn.to/2nw1QN5" rel="noopener ugc nofollow noopener noopener" target="_blank"><em class="markup--em markup--p-em">The Manager’s Path</em></a><em class="markup--em markup--p-em">, available on Amazon and Safari Online!</em></p></div></div></section>Camille Fournierhttp://www.blogger.com/profile/05090020862261633248noreply@blogger.com0tag:blogger.com,1999:blog-8221886912876606828.post-5849563683183758382022-08-14T09:57:00.001-07:002022-08-14T09:57:22.778-07:00The Product Culture Shift<p>Adding product management to more traditional software infrastructure organizations, sometimes with a shift towards platform engineering, is all the rage today. As someone who has done both these things, it doesn’t surprise me to see so many people struggling to make it work. Both of these shifts require going from a siloed, process, tech-focused mindset to a portfolio, usability, and customer-focused mindset. This is a hard transformation, and it’s easy for people who have spent their whole career building infrastructure to misunderstand what product and platform really mean. So I thought I’d share the secret to making this work.</p><h3 class="graf graf--h3" name="9a0e">Your whole engineering culture has to change.</h3><h4 class="graf graf--h4" name="a25d" style="text-align: left;">Yes, seriously.</h4><p class="graf graf--p" name="2c51">Infrastructure organizations tend to be good at many things. They are good at cost management, vendor negotiations, and running systems at scale. They have specialists who know the murky depths of databases, the nuances of networking, and how to debug nasty kernel issues. They may even be good at triaging bug requests from tens or hundreds of teams, planning large-scale failure tests, and coordinating massive migrations.</p><p class="graf graf--p" name="c3e8">Unfortunately, they are not usually very good at thinking about the people who will use their systems, taking their preferences into account, and treating them like customers who they are trying to keep. Why should they? The people who use their systems are a captive audience! As I mentioned in my post about <a class="markup--anchor markup--p-anchor" data-href="https://skamille.medium.com/product-for-internal-platforms-9205c3a08142" href="https://skamille.medium.com/product-for-internal-platforms-9205c3a08142" rel="noopener" target="_blank">product for internal platforms</a>, this is a major challenge that platform and infrastructure teams have to overcome to build great products.</p><p class="graf graf--p" name="9c07">This culture, with its focus on cost, scale, and process, over people and usability, is very hard to root out. And you don’t want to lose all those rare skills in the process. So what do you do?</p><h3 style="text-align: left;"><strong class="markup--strong markup--h4-strong">You can’t just rub product managers on it and call it a day.</strong></h3><p class="graf graf--p" name="671a">To start, let’s be clear about one thing: as tempting as it might be, just hiring product managers won’t fix this problem. Even if you could find enough good product managers who want this type of job, which you can’t, product managers are only useful when they are paired with willing engineering teams. If the engineering teams don’t feel a sense of ownership for delivering a great product to their customers, product managers are unlikely to close that gap, and they will more likely turn into glorified backlog groomers than true product leaders.</p><h3 style="text-align: left;"><strong class="markup--strong markup--h4-strong">You need to change the way you support your products.</strong></h3><p class="graf graf--p" name="d57c">The ticket system black hole is a great way to make your customers feel more like a burden than a focus. I understand that it is hard to manage all the incoming requests for your teams, but taking a close eye to how you provide support, what your response time is for questions, and how you triage incoming issues is critical to this transition. Your engineers should spend time supporting their products. If they are not regularly answering questions, they are missing a chance to appreciate the pain that customers are facing when trying to use the systems. Be careful about making this optional, or leaving it to only junior engineers. Your senior folks will not build the kind of humane products that you need if they are incapable of interacting with the users in a polite and helpful way, no matter how brilliant they might seem. If you have someone you can’t trust to engage productively in help situations, watch out, because this person is probably not building products that are easy to use. Over time, you may find yourself redoing a lot of their work because it is harder to support and drives a high volume of complaints.</p><h3 style="text-align: left;"><strong class="markup--strong markup--h4-strong">You need to update your interview process.</strong></h3><p class="graf graf--p" name="8e12">I recommend adding screening for what I call “customer empathy” to all of your interview lineups. This doesn’t have to be deep, it can be simple as asking them how they think about how they write code so that other developers can understand it, or what their approach is to answering questions about the systems they have built. But you want to set the tone that you expect your developers to think not just about how to build the systems, but about the people who are going to use them or work with them.</p><h3 style="text-align: left;"><strong class="markup--strong markup--h4-strong">You need to update your systems of recognition and reward.</strong></h3><p class="graf graf--p" name="282e">If you only promote people who solve big technical problems, you’re going to have a hard time retaining the people who do the work to smooth out the usability edges, actively listen to the customer teams, and adjust their work priorities to fix the stuff that is causing the most pain. So look closely at what you are celebrating, paying, and promoting, and make sure you are including work that makes the product better whatever that looks like, even if it isn’t the hardest technical bits. Remember, this is a cultural change, and cultural changes that don’t involve changes to what is valued when it comes to recognition and rewards are destined to failure.</p><h3 style="text-align: left;"><strong class="markup--strong markup--h4-strong">Do you have too many project managers?</strong></h3><p class="graf graf--p" name="3673">There may always be some need for project managers, but in infrastructure organizations, heavy reliance on project managers can result in a lack of up-front technical planning around one of the most common infrastructure team tasks: migrations. If your migrations are so painful that both your team and your customer teams need project managers to understand where all the dependencies lie and track what is happening, you are not taking ownership of the user experience for your software. Yes, migrations are part of your UX! I am astonished at how often infrastructure teams offer new systems that do not have compatibility with the systems they are replacing, and expect the customers to do all of the work to migrate to those new systems, often on a timeline dictated by the initiating team.</p><p class="graf graf--p" name="b2b0">If you are moving to a platform model, you are going to need to own much more of the migration than you have up until now. That platform value add must include lowering the migration pain for customers, which means getting better at doing them entirely yourselves. By limiting the number of project managers now, you force engineers to face project management work that they will not want to do. And the good ones will realize that if they created automation to support the migration, whether it is detection of dependencies, compatibility bridging libraries, or abstractions that allow them to change the internals without changing the client libraries, they won’t have to do so much of that tedious project management work. By saving themselves time, they will save their customers time. So limiting project managers is a good forcing function. Just make sure that you are giving teams time to do this work, and not just making them miserable or shifting the project management onto your new product managers.</p><h3 style="text-align: left;"><strong class="markup--strong markup--h4-strong">Your teams are going to spend more time talking to customers, and less time purely writing code.</strong></h3><p class="graf graf--p" name="4cd1">There’s no way to shortcut the product mindset transition for your engineering team. You can’t just add a product manager or a customer advisory board meeting once a quarter and call it a day. The team will need to spend more time with the customers, and more time strategically planning for how to address holistic concerns, rather than just triaging the latest set of customer complaints. There will be an up-front cost as you change the way people work. They may complete fewer tickets or other process-oriented measures of productivity, and the pace of work might look slower than it did when they were just churning through a never-ending backlog of tickets. But over time, the work that is produced should be better, as measured by customer surveys, adoption, migration timelines, and eventually, engineering productivity.</p><h3 style="text-align: left;">Keep it fun!</h3><p class="graf graf--p" name="c083">By the time companies go through this transition, they are often in a deep state of us-vs-them between their infrastructure organization and their other business/product engineering teams. This situation never feels good to the infrastructure organization. No matter how much they may claim outwardly that their users are hopeless or ungrateful (or worse), it is simply not much fun to have an antagonistic relationship with your users, and to feel like you are deep inside of an us-vs-them dynamic with colleagues. So while this transition is going to be tricky, it can also be fun if you let it. Get feedback from your users about what they love about the product. Share kudos as they come in, and take the time to celebrate improvements in your customer satisfaction metrics. Make sure your teams are part of the celebrations when their work enables an application team to do something they couldn’t do before. This is an exciting opportunity, a chance to learn, to modernize your approaches to work, and to create a more positive culture, and leading with a positive attitude will make all the difference in how fun it is for everyone.</p><h3 style="text-align: left;"><strong class="markup--strong markup--h4-strong">Wrapping up</strong></h3><p class="graf graf--p" name="42c2">In many ways, this cultural shift echoes the changes that happened during the “devops”/SRE transformation. Engineers in SRE-focused organizations do not build code that they carelessly throw over the wall to an operations team. In the same way, engineers in a product-focused organization do not build software without consideration of the users of that software. These transformations ask more of the engineering teams, but deliver higher-quality outcomes as a result. It’s expensive and takes time but I promise you, it’s worth it.</p><p class="graf graf--p" name="2e04"><em class="markup--em markup--p-em">Enjoy this post? You might like my book, </em><a class="markup--anchor markup--p-anchor" data-href="http://amzn.to/2nw1QN5" href="http://amzn.to/2nw1QN5" rel="noopener ugc nofollow noopener noopener" target="_blank"><em class="markup--em markup--p-em">The Manager’s Path</em></a><em class="markup--em markup--p-em">, available on Amazon and Safari Online!</em></p>Camille Fournierhttp://www.blogger.com/profile/05090020862261633248noreply@blogger.com0tag:blogger.com,1999:blog-8221886912876606828.post-834478152344400092022-01-15T13:01:00.001-08:002022-01-15T13:01:32.796-08:00Structural Lessons in Engineering Management<p class="graf graf--p" name="75b8">Software engineers are attracted to formulas, algorithms, and structures. As people whose job it is to take ideas and turn them into predictable executable code, it is unsurprising that we’re drawn to ways of thinking that categorize and systematize things. This attraction continues as engineers become engineering managers and leaders. I should know, I wrote<a class="markup--anchor markup--p-anchor" data-href="http://amzn.to/2nw1QN5" href="http://amzn.to/2nw1QN5" rel="noopener" target="_blank"> a pretty popular book</a> that is full of best practices, tips, tricks, and process suggestions to apply to the various challenges of leadership.</p><p class="graf graf--p" name="3c77">However, I think it’s worth talking about the downside of going too far with structural thinking as it pertains to teams and organizations. Let’s take a common area where this structural approach happens, namely that of organizational structures and interactions.</p><p class="graf graf--p" name="616b">There are certain rules that I believe in, one of which is that engineering managers do not scale well beyond about 7–8 direct reports. It’s hard to keep the context of what each of these people is doing and thinking about in your head well enough that you can effectively guide them. You end up spending an outsized amount of time on management tasks when your direct team size grows much beyond this number; or, even worse, you just start doing a bad job at those management tasks because you don’t have the time to do them well.</p><p class="graf graf--p" name="88d3">On the flip side, many organizations do not want managers who only manage a couple of people directly. Someone who manages only two people is often in a limbo state: are they an individual contributor? Are they a manager? The HR system is binary: if they have direct reports, they must be a manager. But the reality is that if you only manage a couple of people, most of your time is spent doing things other than management. If this person is a new manager, they may not be learning the things they need to learn to grow into a confident managerial role. On the other hand, if this person is and wants to remain an individual contributor, their management is likely to be a bit lacking for these two individuals.</p><p class="graf graf--p" name="0c56">The temptation is to move from these two beliefs into the notion that you must create a clean tree structure for your organization. Each manager manages three to eight people; when a team grows too large you rebalance the tree. All is clean, and easy; our organizational structure works.</p><p class="graf graf--p" name="1e14">Experienced managers know how quickly this falls apart. People quit, and suddenly the manager of 5 people only has 2 direct reports. Managers don’t just drift between teams depending on the immediate size of the organization, they have skills and interests that make them sticky to their group. Individual contributors get rightly frustrated when their manager changes too often, and they prefer managers who have some understanding of their work. The teams need to have some coherence of vision and purpose; hiring is never a steady drip but comes and goes in bursts. Your ideals quickly fall apart when faced with the reality of a living organization and the needs of the people in it, so your trees sometimes have skinny branches, and sometimes very fat ones. The best you can do is try to nudge it back into shape over time, or very occasionally, reorganize into something more appropriate.</p><figure class="graf graf--figure" name="9476"><img class="graf-image" data-height="2448" data-image-id="1*aNl6ZvwbIQtnzZTyrTGZgA.jpeg" data-is-featured="true" data-width="3264" height="240" src="https://cdn-images-1.medium.com/max/1600/1*aNl6ZvwbIQtnzZTyrTGZgA.jpeg" width="320" /><figcaption class="imageCaption">Photo by <a class="markup--anchor markup--figure-anchor" data-href="https://unsplash.com/@gillystewart?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText" href="https://unsplash.com/@gillystewart?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText" rel="noopener" target="_blank">Gilly Stewart</a> on <a class="markup--anchor markup--figure-anchor" data-href="https://unsplash.com/s/photos/tree?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText" href="https://unsplash.com/s/photos/tree?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText" rel="noopener" target="_blank">Unsplash</a></figcaption></figure><p class="graf graf--p" name="62f4">Another failure mode happens when leaders get enamored of applying engineering analogies to define team interactions. APIs are a fine concept but the idea that team interactions can be strictly defined by an API is as laughable as the idea that programmers won’t figure out a way to exploit every undocumented feature you provide in one. In this case, <a class="markup--anchor markup--p-anchor" data-href="https://www.hyrumslaw.com/" href="https://www.hyrumslaw.com/" rel="noopener" target="_blank">Hyrum’s Law</a> applies as much to engineering organizations as it does to software. Humans will and must talk to each other, trade favors, and negotiate based on changing circumstances. When you are in the thick of trying to get things done, you will use what you can find, whether it’s an undocumented API or an engineer on another team who is willing to lend a hand.</p><p class="graf graf--p" name="2abb">Ironically, a lot of software engineers turned managers believe that they are taking humans into account with these rigid structures. When you see the world in systems, interactions, and efficiencies, you can trick yourself into believing that the humans inside of these systems will be happier if the system is well-organized. While I agree that there is value to organizing your teams effectively, the marginal value that the teams might experience is likely to be offset by the unintentional friction that happens for the people who don’t fit perfectly into your structure. If you don’t work to stay ahead of what the people in your team want and need, if you don’t create growth opportunities or appropriate technical challenges even though it’s not the most optimal thing for the system as it currently exists, you will find yourself losing good engineers and managers. The people in the system are much trickier than you are imagining, and the structure that accounts for their skills and happiness will have organic features as much as centrally-planned ones.</p><p class="graf graf--p" name="955f">Managing a startup team at a new and growing company can lead inexperienced managers to believe that they can define the structures and processes to be perfectly tuned to what their company needs at the moment. I went through this phase myself, and I know the temptation to allow the ever-changing demands of startup life to justify changing and tweaking of teams and processes and projects in pursuit of the ideal execution machine. While managing a large organization at a more stable company, I’ve come to appreciate the cost and overhead of such a systems-focused approach. When you are thinking in terms of years and not months, it becomes important to accept that you may hang out in imperfect structures for many months or even longer, because you are trying to hang onto people for years.</p><p class="graf graf--p" name="9fe2">So, new leaders, read those books and expose yourself to those ideas, but don’t stop there. Listen to your people, and don’t be afraid to break your perfect structures to accommodate their needs. They are your best source of learning, and your most valuable asset.</p><p><em class="markup--em markup--p-em">Enjoy this post? You might like my book, </em><a class="markup--anchor markup--p-anchor" data-href="http://amzn.to/2nw1QN5" href="http://amzn.to/2nw1QN5" rel="noopener ugc nofollow noopener noopener" target="_blank"><em class="markup--em markup--p-em">The Manager’s Path</em></a><em class="markup--em markup--p-em">, available on Amazon and Safari Online!</em> </p>Camille Fournierhttp://www.blogger.com/profile/05090020862261633248noreply@blogger.com0tag:blogger.com,1999:blog-8221886912876606828.post-57661791259525187722021-10-09T12:12:00.000-07:002021-10-09T12:12:07.581-07:00How New Managers Fail Individual Contributors<p> Most companies have carefully created separate senior career tracks that provide details of the differences between being a manager and being an individual contributor (IC). And yet, many people still believe that you can’t get ahead without becoming a manager, and many companies who want more senior individual contributors struggle to promote people on this path. This is a shame; great engineers really shouldn’t need to manage large teams to get promoted, and companies lose out on a critical skillset when they push all of their good engineers into management.</p><p class="graf graf--p" name="b249">Why do we have this problem despite all our efforts? I believe the problem with keeping people on the technical track starts with managers. Specifically, it starts with new managers. You see, most people become managers right at the point where career tracks split between “technical” and “management” specializations. The result is that many new managers have most recently been very technical, yet they have no idea what it means to climb the technical track, but they will be managing people who want to follow that path. To be a great manager, you can’t afford to let the ICs on your team feel that they have no career path, so it’s up to you to manage this well. Here are some common pitfalls that you should work to avoid.</p><h4 class="graf graf--h4" name="ebde">1. Doing all the technical design work yourself</h4><p class="graf graf--p" name="2804">You’re just coming off of being an IC or maybe a tech lead, so you are still pretty deep in the technical details (especially if you’re now managing the team you were working on). You might still be writing some code, which is fine if you’re managing a very small team. But it is critical that you step back on the technical decisions to make room for the team members to own things and grow.</p><p class="graf graf--p" name="a696">This is going to be hard because you may have a small team with a lot on its plate, and the other ICs may not have your skills at communication or project management. If you respond by filling in for their skill gaps, you are going to quickly hit two problems. First, you won’t be able to scale because you’ll be too busy doing technical stuff to take on a bigger team. Second, you won’t be able to scale because you won’t have a person to whom you can delegate.</p><h4 class="graf graf--h4" name="689c">2. Doing all of the project management yourself</h4><p class="graf graf--p" name="c921">This one you would probably love to give up, I know. If you have a very small team, as a manager you’re the right person to do most of the project management for the team. But for their career growth, your technical track folks also need to learn how to run projects themselves. The more senior you get on the technical track, the more that you will be expected to understand not only how to solve really hairy technical problems but how to break down the solution into milestones, and even into projects that can be worked on by multiple people.</p><p class="graf graf--p" name="bd9e">Teaching someone how to run a project is painful, and they will often say that they don’t want to do the work, don’t want to learn it, and make your life difficult in the process. And yet, teaching your ICs these skills is one of the best things you can do for their future promotion prospects! Plus, it’s one of the best things you can do for your own future prospects. A manager who successfully creates a tech lead capable of solid design work and project management now has the bandwidth to take on more and expand their scope.</p><h4 class="graf graf--h4" name="3bfa">3. Neglecting to Give Feedback</h4><p class="graf graf--p" name="8e5a">Many new managers are comfortable giving technical feedback, and uncomfortable giving other kinds of feedback. They freely criticize the design and technical work of their team, but they don’t challenge their team members on other growth areas like collaboration, communication style, or project ownership. The result is the impression that management is the way to have technical authority over a group, which leads ICs to wonder what the technical track is even for.</p><p class="graf graf--p" name="c0a9">One of the ways to give feedback that will stick is to give it in context of career growth. Take the time to understand the technical and non-technical skills that your company looks for in senior engineers, and use that framing to set goals on both of these aspects for your team. This will force you to pay attention to more than just the technical delivery, and make it easier to talk about non-technical areas for improvement as needed for future promotion.</p><h4 class="graf graf--h4" name="8440">4. Hoarding information</h4><p class="graf graf--p" name="5111">You’re now in a position where people will naturally pass information on to you. You may be in more planning meetings with the product team, or staff meetings with your boss and peers, and you may become the person who gets pinged directly when someone has a question or request for your group. This means that you’ve now got a lot more details about what is going on around your team, and this information is critical for you to lead your team well. You must distill this information and then communicate it to your team in a way that helps them understand their work.</p><p class="graf graf--p" name="6788">When you don’t give your team the context for the work and just pass on tasks and work items to them, you make it clear that they are simply “doers” and your job is the job of “decider.” There is a fine line between giving the team focus time and excluding them from meetings where they would get necessary information and context to feel ownership of the projects. Your growth challenge is to learn the balance of providing information to the team and inviting them along to get that information, while not overwhelming them with meetings.</p><h4 class="graf graf--h4" name="fef3">5. Focusing Too Much On Your Personal Output</h4><p class="graf graf--p" name="5a19">As a manager, your output is not measured by your individual work. Rather, your output is measured by the work of your team and the people that you influence. The work you choose to do, and the work you choose to neglect or delegate, will lead to amplified outcomes in both positive and negative directions.</p><p class="graf graf--p" name="74a4">If you continue to focus on your personal contributions, such as writing code, technical design, and day-to-day decision-making, you will constrain the output of your team to only what you can fit into your schedule. If it’s your code that gets you over the finish line for every project, you aren’t providing multiplicative value for the team, you’re providing the additive value of your work as an engineer. When you turn your focus to the work you can do to improve the team’s output, by training them to do these tasks, ensuring that they work well as a team, and giving them the context they need to make decisions themselves, you now start to create multiplicative value. When they become more productive and less reliant on your hands-on work, your time is freed to identify bigger challenges. This is the path to growth for the whole team, but it’s hard to find if you’re heads-down in the details.</p><h4 class="graf graf--h4" name="184c">Conclusion</h4><p class="graf graf--p" name="d615">New managers, make sure that you aren’t trying to be a senior engineer who has direct reports. If your heart is in the code and systems, perhaps you should be on that technical track yourself! Otherwise, remember that your job is now about generating leverage by developing your team, which means delegating the technical work to them while helping them identify other skills they will need to successfully grow as an engineer. If you can do this, you’ll have a bright career in management, and a loyal group of amazing senior individual contributors to work with in the future.</p><p class="graf graf--p" name="0320"><em class="markup--em markup--p-em">Originally published on </em><a class="markup--anchor markup--p-anchor" data-href="https://leaddev.com/skills-new-managers/common-management-failures-developing-individual-contributors" href="https://leaddev.com/skills-new-managers/common-management-failures-developing-individual-contributors" rel="noopener" target="_blank"><em class="markup--em markup--p-em">leaddev.com</em></a></p><p class="graf graf--p" name="ab8b"><em class="markup--em markup--p-em">Enjoy this post? You might like my book, </em><a class="markup--anchor markup--p-anchor" data-href="http://amzn.to/2nw1QN5" href="http://amzn.to/2nw1QN5" rel="noopener ugc nofollow noopener noopener" target="_blank"><em class="markup--em markup--p-em">The Manager’s Path</em></a><em class="markup--em markup--p-em">, available on Amazon and Safari Online!</em></p>Camille Fournierhttp://www.blogger.com/profile/05090020862261633248noreply@blogger.com0tag:blogger.com,1999:blog-8221886912876606828.post-60789980927511762112021-06-12T15:38:00.000-07:002021-06-12T15:38:26.742-07:00An incomplete list of skills senior engineers need, beyond coding<h3 style="text-align: left;">For varying levels of seniority, from senior, to staff, and beyond.</h3><ol class="postList"><li class="graf graf--li" name="8ad8">How to run a meeting, and no, being the person who talks the most in the meeting is not the same thing as running it</li><li class="graf graf--li" name="b2d0">How to write a design doc, take feedback, and drive it to resolution, in a reasonable period of time</li><li class="graf graf--li" name="6fff">How to mentor an early-career teammate, a mid-career engineer, a new manager who needs technical advice</li><li class="graf graf--li" name="2ae3">How to indulge a senior manager who wants to talk about technical stuff that they don’t really understand, without rolling your eyes or making them feel stupid</li><li class="graf graf--li" name="2807">How to explain a technical concept behind closed doors to a senior person too embarrassed to openly admit that they don’t understand it</li><li class="graf graf--li" name="d475">How to influence another team to use your solution instead of writing their own</li><li class="graf graf--li" name="aa76">How to get another engineer to do something for you by asking for help in a way that makes them feel appreciated</li><li class="graf graf--li" name="4cf8">How to lead a project even though you don’t manage any of the people working on the project</li><li class="graf graf--li" name="f68d">How to get other engineers to listen to your ideas without making them feel threatened</li><li class="graf graf--li" name="eb2d">How to listen to other engineers’ ideas without feeling threatened</li><li class="graf graf--li" name="c3d1">How to give up your baby, that project that you built into something great, so you can do something else</li><li class="graf graf--li" name="43df">How to teach another engineer to care about that thing you really care about (operations, correctness, testing, code quality, performance, simplicity, etc)</li><li class="graf graf--li" name="1b1c">How to communicate project status to stakeholders</li><li class="graf graf--li" name="2e0d">How to convince management that they need to invest in a non-trivial technical project</li><li class="graf graf--li" name="e67d">How to build software while delivering incremental value in the process</li><li class="graf graf--li" name="756e">How to craft a project proposal, socialize it, and get buy-in to execute it</li><li class="graf graf--li" name="9339">How to repeat yourself enough that people start to listen</li><li class="graf graf--li" name="edf1">How to pick your battles</li><li class="graf graf--li" name="c03a">How to help someone get promoted</li><li class="graf graf--li" name="df59">How to get information about what’s really happening (how to gossip, how to network)</li><li class="graf graf--li" name="e579">How to find interesting work on your own, instead of waiting for someone to bring it to you</li><li class="graf graf--li" name="0d26">How to tell someone they’re wrong without making them feel ashamed</li><li class="graf graf--li" name="91fa">How to take negative feedback gracefully</li></ol><p class="graf graf--p" name="9951"><em class="markup--em markup--p-em">Enjoy this post? You might like my book, </em><a class="markup--anchor markup--p-anchor" data-href="http://amzn.to/2nw1QN5" href="http://amzn.to/2nw1QN5" rel="noopener nofollow noopener noopener" target="_blank"><em class="markup--em markup--p-em">The Manager’s Path</em></a><em class="markup--em markup--p-em">, available on Amazon and Safari Online!</em></p>Camille Fournierhttp://www.blogger.com/profile/05090020862261633248noreply@blogger.com0tag:blogger.com,1999:blog-8221886912876606828.post-4995645839733390872021-05-29T13:40:00.000-07:002021-05-29T13:40:00.829-07:00Management Basics: Determining a Performance Rating<p> <em class="markup--em markup--p-em">originally posted on </em><a class="markup--anchor markup--p-anchor" data-href="https://leaddev.com/mentoring-coaching-feedback/engineering-management-101-evaluating-your-teams-performance" href="https://leaddev.com/mentoring-coaching-feedback/engineering-management-101-evaluating-your-teams-performance" rel="noopener" target="_blank"><em class="markup--em markup--p-em">LeadDev.com</em></a></p><p class="graf graf--p" name="4473">One of the most stressful parts of the end-of-year process for managers is the dreaded performance rating. This process forces you to boil down all of the work that a person did over the year, all of their accomplishments and misses, into a numeric score (often from 1–5) that may also come with words like ‘meets expectations’, ‘exceeds expectations’, or the unhappy ‘misses expectations’.</p><p class="graf graf--p" name="3f4a">If you work for a company that has a ‘pay for performance’ model, your rating will influence the employee’s compensation. It may be used as an input for promotions, and yes, as a factor in firing or laying off employees. And so while this process is painful, every manager needs to get comfortable with assigning ratings to their engineers, and justifying those ratings to both the person receiving the rating, and potentially to their peers, boss, or other stakeholders who have a say in the distribution of rating scores at the company.</p><p class="graf graf--p" name="f304">Your manager rating is a combination of measurable inputs and your own judgment. Today, I’m going to focus on how you can start to get comfortable with this step, by developing your own judgment and the supporting metrics you can use to guide your ratings.</p><h4 class="graf graf--h4" name="e6c7">Evaluations start long before it’s time to actually determine a rating</h4><p class="graf graf--p" name="1e43">The first major input in any kind of fair evaluation is based on the work the employee needed to accomplish, and the work they did accomplish. This process starts with both goal-setting and a review of the expectations of the role, as well as any areas you already know they need to improve on. This may seem obvious but, as we’ll see, it is actually a tricky thing to get right!</p><p class="graf graf--p" name="6faa">As an example of using goal-setting as an input in performance rating, let’s explore a method that splits goals up into three categories: must be achieved, stretch goals, and moonshot goals.</p><p class="graf graf--p" name="c4e9">By setting ‘must be achieved’ goals, you inform the employee on what the important work for the year should be, given their level and role. Then you collaboratively think about what stretch goals might look like, including a goal or two that would be really outstanding if they could achieve it — a moonshot goal. When you have your whole organization calibrated on how to set these kinds of goals, you can use them as a critical input for performance rating. If someone met the base goals, they probably met expectations. If they met the base goals and some of the stretch goals, they exceeded or substantially exceeded expectations. If they achieve base, stretch, and a moonshot goal, that would imply a year of incredible achievement that would support the highest rating of all.</p><p class="graf graf--p" name="8ba3">Of course, the downside of goal-setting is that goals often become irrelevant in the course of a year. This is where your judgment must come into play. When they missed a goal, was it because it became irrelevant, because they failed to execute, or because they were unavoidably busy with unplanned critical work? Ideally you revisit goals regularly and adjust them when they become irrelevant, but I’m a realist and know that many people forget to do this or get too busy to bother. It’s a lot of work to constantly track this! So most of us must get comfortable with looking across the scope of goals (hit, missed, and deferred) and value them as they are.</p><p class="graf graf--p" name="0f3a">Judgment is a major part of evaluating more senior people’s goals, particularly more-senior managers. On the one hand, they will tend to be responsible for the achievements of a team of people, and many things can happen to a team in a given year to derail their goals. On the other hand, the more senior a manager gets, the more they are expected to anticipate ways in which their team may fail to achieve their goals; this anticipation and course correction is part of performing well as an experienced manager. Only you can tell the difference between a manager who was blindsided by events and a manager who just failed to plan well, or who couldn’t course correct their team effectively.</p><h4 class="graf graf--h4" name="2870">Decide on your own axes of evaluation and attempt to apply them evenly</h4><p class="graf graf--p" name="3578">A manager I used to work with had a very methodical approach that he used to evaluate managers on his team. He had <a class="markup--anchor markup--p-anchor" data-href="https://medium.com/@inowland/the-seven-areas-of-software-management-be89d213ea7" href="https://medium.com/@inowland/the-seven-areas-of-software-management-be89d213ea7" target="_blank">seven characteristics of management</a> that he considered essential to doing the job, and would score each manager on each area, then roughly average them to get a final score. A different manager that I worked with at Rent the Runway did something similar with our four <a class="markup--anchor markup--p-anchor" data-href="https://dresscode.renttherunway.com/blog/ladder" href="https://dresscode.renttherunway.com/blog/ladder" rel="noopener" target="_blank">engineering ladder</a> attributes. She would grade each person based on their level and role, and use that to justify how she rated her team.</p><p class="graf graf--p" name="e600">I find this approach to be a helpful part of my ratings process. Looking across a set of attributes that I believe are important forces me to think about all of the skills a person brings to the table, and how they seem to be doing at each of them. This helps me identify strengths and weaknesses, and structures my thinking when I am evaluating across people in similar roles.</p><p class="graf graf--p" name="2193">Rating by category works when you have a lot of clarity about what is important (as in the seven characteristics of managers), or a ladder that is well-written to support this. But it does have its downsides, and these will become apparent when you try to put this into practice. People are not easy to put into boxes. You may have a manager that is incredibly weak in one area and incredibly strong in another. Does this average out? Or are they actually underperforming, because their weak area is so essential that it means they aren’t doing their job? Or on the flip side, are they over-performing because, for this role and team, the weak area doesn’t matter so much? Now you have to add judgment into the mix.</p><p class="graf graf--p" name="b3e9">It’s also hard to apply this model when you have a team of people who all have somewhat different jobs. It’s very hard to write level criteria that works well for both front-end and back-end engineers, let alone systems specialists, reliability engineers, and DBAs. Then add in the fact that you may be managing someone who is in a bespoke role, say developer relations or technical writing. Now you may not have enough data points to make sure that you are rating the person fairly, because there is really no one else for you to compare them to.</p><h4 class="graf graf--h4" name="f183">The final component has to be your own judgment</h4><p class="graf graf--p" name="e8aa">This brings us to the final aspect of performance rating: manager judgment. As with all things in the world of people management, there is no perfect algorithm you can apply to ensure total fairness and accuracy. You do not want to set yourself up to deny good ratings to people doing good work when they don’t fit perfectly in a box, or when they had all of their goals upended by a strategic shakeup halfway through the year. But you also don’t want to unfairly reward or punish people through an arbitrary process that relies on how much you like or dislike them.</p><p class="graf graf--p" name="c46c">Setting clarity at the beginning of the performance evaluation period via goal-setting and job alignment is important because it gives your employees a clearer idea of what they are going to be evaluated against. Breaking roles down into components and rating each person against each component helps you consider a balanced picture of someone’s strengths and weaknesses across the areas that matter. But ultimately, these inputs are merely some of the data you need, and you must consider the full picture of their work against the ever-changing requirements and challenges of your workplace.</p><p class="graf graf--p" name="cffc">The most interesting and useful part of this exercise is comparing what you get from this data against your gut reaction to the rating you think someone should get. If you are open-minded, the data will show you that you’re off both high and low in different cases.</p><p class="graf graf--p" name="8ebe">This is an opportunity for you to broaden your thinking: what aspects of this role are really important but unstated in our level guidelines? It will force you to postmortem your own leadership: how did we miss on the goals here so badly? And sometimes, it will force you to acknowledge your own bias: why do I always want to give this kind of person a lower rating even though objectively their work looks as good as this other kind of person?</p><p class="graf graf--p" name="89c3">Your own ratings are rarely the final step. Most companies force an alignment across teams and managers via a calibration exercise in order to ensure ratings are fairly applied across the company. But if you spend good time up-front getting very clear in your own mind the rating you believe someone deserves, and the reasoning behind that rating, you are well-prepared to go into that calibration exercise and defend your ratings with thoughtfulness and care. And you want to be prepared, because once the rating is set, you’ll have what may be the hardest conversation of all: the one where you share the rating with the employee.</p><p class="graf graf--p" name="2219"><em class="markup--em markup--p-em">Enjoy this post? You might like my book, </em><a class="markup--anchor markup--p-anchor" data-href="http://amzn.to/2nw1QN5" href="http://amzn.to/2nw1QN5" rel="noopener nofollow noopener noopener" target="_blank"><em class="markup--em markup--p-em">The Manager’s Path</em></a><em class="markup--em markup--p-em">, available on Amazon and Safari Online!</em></p>Camille Fournierhttp://www.blogger.com/profile/05090020862261633248noreply@blogger.com0tag:blogger.com,1999:blog-8221886912876606828.post-42934097042443276972021-01-24T09:33:00.000-08:002021-01-24T09:33:35.561-08:00Make Boring Plans<p>You’re probably familiar with the concept of <a href="https://mcfunley.com/choose-boring-technology" target="_blank">Choose Boring Technology.</a> If you’re not, I’ll wait for you to read the excellent blog post by Dan McKinley that inspired a much-needed correction in tech to balance “innovation” with stability. I’m here to take this to the next level, and talk about how “boring” should apply not just to your technology choices, but to your plans.</p><p>I spoke to someone several months ago who was frustrated with their management chain. They were anxious about the fact that the management chain was always pushing on delivery in an unpredictable way. The team felt really high pressure, even though the projects they were working on were all part of long-running infrastructure renovations. Why was this so stressful? Why, they asked, was the plan not already laid out? Why isn’t this boring?</p><p><span style="font-size: medium;"><b>Why isn’t this boring?</b></span></p><p>It might say something about the area that I focus on, Platform Engineering*, that “why isn’t this boring” would ever come up. You see, usually when people are in this situation, they blame everything but the lack of planning for their problems. It is a common belief in engineering that, with a clear enough vision, the rest of the pieces of work will fall into place. With a well-understood goal and smart engineers, the idea is that you can trust that people will work towards that vision faithfully and deliver something great. And this does, in rare cases, seem to work. After all, half of the hiring wisdom of the past has been “hire smart people and get out of their way.” Magic can happen with a small, highly-motivated group of people building a new thing towards a clear goal.</p><p>However, this concept of building towards a grand vision falls apart when you are building the underlying software that other engineers rely on. For better and for worse, Platform often has to be the place where we push new things to the rest of the company. A big change in the platform is the definition of an innovation token being spent. You want to move to Kubernetes? You’re gonna spend a lot of time figuring out how to operate it well in your environment, to start. You want to support a massive monorepo for the whole company? Hello innovation tokens everywhere, as you try to make it scale and perform well for all of your engineers and all of the languages they want to use. Speaking of new languages, you want to introduce Rust, or O’Caml, or even just C++17? The platform will have to support it.</p><p>Before you go blaming the Platform team for spending all of the innovation tokens for the company, remember that these initiatives are often driven by someone else. If Platform doesn’t support Kubernetes, some team will decide to build shadow infrastructure because they’re convinced that it will solve the problem they have to handle with their tens of microservices, and then it will land in the lap of Platform after a year with none of the work done to make it easy to operate, but all of the operational expectations anyway. Our goal is to build just enough ahead of you so that when you realize you need the capacity, it’s there, or can be with minimal fuss, and it’s reliable to boot.</p><p><span style="font-size: medium;"><b>Novel Technology Deserves Boring Plans</b></span></p><p>Since we often end up in the land of novel technology, we owe it to ourselves and our customers to be boring in other ways. And the most important way that a Platform team can be boring is by writing boring plans.</p><p>It’s great to have a vision for the future of the platform. To achieve this vision, a non-trivial amount of our job is not just building new big, scalable, complex software infrastructure, but moving everyone from the last generation of this software infrastructure to the next generation. Upgrade the programming languages, the operating systems, the libraries. Move from OpenStack to Kubernetes, from on-prem to the cloud, from maven to bazel, from svn to git. Migrate from the old storage system that was optimized for a rare legacy usecase, to a new storage system with higher availability and performance.</p><p>Making these changes happen, under the covers, has both interesting parts and boring parts. If you’re not a platform engineer, you shouldn’t see the interesting parts. The interesting parts are where we go and tune the kernel to perform well for our workloads. The interesting parts are where we build out automatic failover, so that we can meet the availability needs of the workloads. The interesting parts are the many patches we might contribute back to the inevitably-broken open source projects that hold half the world together but still don’t seem to understand how to work with FQDNs. The interesting parts are where we understand deeply the dependencies of our technology stack, the opportunities and limitations, and build solutions for our customers that fix limitations and unlock new opportunities.</p><p>When we don’t attend to the boring parts by making our plans predictable, the interesting parts turn into extra stress on top of the overwhelming anxiety of juggling these moves. When you make plans that start and end with the vision “we will move everyone to the public cloud, and it will be great,” you find yourself in the exhausting situation of running all of your old infrastructure, trying to figure out the new cloud stuff, and dealing with customers who are confused and angry that the thing they want to do doesn’t seem to quite work in either world.</p><p>Contrast this to the team that turns that vision into boring plans. They start with a small proof of concept, migrating perhaps a single application and learning in the process. Then they do the work of looking across other applications on the old platform, to see which ones are similar to the one that is now in the cloud. They work with those users to get them migrated and running, all the while gaining comfort with this new environment and uncovering the interesting gotchas. They write down what they’re learning, so that each new step in the migration builds on the last, and others can be pulled in without a huge knowledge transfer. The team focuses on the hard parts of the moment, whether they are figuring out data mirroring, or fixing a bug in a popular open source project, and they are free from the anxious overhead of wondering what is happening tomorrow. The users are also free from the stress of wondering when the work they need will be delivered, because the team has communicated plans that account for this process of iteration, learning, and gradual migration.</p><p><span style="font-size: medium;"><b>A Strategic Plan Is Obvious and Simple, Even Boring</b></span></p><p>Making boring plans is a foundational step in getting good at setting engineering strategy. Strategy is often confused with innovation and vision in tech circles, but they are far from the same thing. Having a future vision and recognizing the potential of innovations is valuable in building great strategy, but strategies that rely on unproven magic bullets are not good strategies. Good strategy identifies a problem with the current situation, proposes a principled approach to overcome it, and then shows you a coherent roadmap to follow. Strategy is not in the business of razzle-dazzle, it’s in the business of getting to the core of the issues so that the solution becomes simple and obvious. Good strategy provides the clarity that enables boring plans.</p><p>To become great at technology strategy, start by getting good at making boring plans. Get clear about the problem you are overcoming with your plans. Make the principles of the work at each stage clear:</p><p></p><ul style="text-align: left;"><li>How do we know when we’re in exploration mode, and how do we know when we’re ready to commit to a direction?</li><li>Have we talked to our users? Do we understand how they are using our systems, and have we made plans that account for their needs?</li><li>What are the problems we’re focused on solving right now, and which problems are we leaving to worry about another day?</li><li>How do we know if we’re on the wrong track, what are the guardrails, milestones, or metrics that tell us whether the plan needs review?</li></ul><p></p><p>Your teams need more than a clear idea of the end state and the hope that smart engineers will inevitably get you there. Plans that are formed around hope are failing plans; hope is not a plan. Plans that change constantly are failing plans. When your plans are constantly changing, it is a sign that you either are making plans that express a certainty you don’t have, or you haven’t done your research to get the right certainty in place. Either of these is a waste of time and an unnecessary stress on the team.</p><p>So leaders, you owe it your teams, and to your users, to free them from the tyranny and stress of uncertainty. You must do the work to go beyond vision, create concrete actions, and make boring plans.</p><span><a name='more'></a></span><p><i>* I’ve defined Platform Engineering before, but the simple description is “the software infrastructure that all of engineering relies on.” Your operation system, storage systems, distributed compute frameworks, and software development tools may all fall into this bucket. To be clear, however, everything in this post tends to apply to any team that is working outside of pure greenfield product development, particularly when the work they do has a lot of downstream impact on users of their systems.</i></p><span><!--more--></span><p><i>Enjoy this post? You might like my book, <a href="http://amzn.to/2nw1QN5" target="_blank">The Manager’s Path</a>, available on Amazon and Safari Online! I also recommend the book <a href="https://amzn.to/366mIze" target="_blank">Good Strategy, Bad Strategy</a>, for those who want to improve their strategic skills. </i></p>Camille Fournierhttp://www.blogger.com/profile/05090020862261633248noreply@blogger.com0tag:blogger.com,1999:blog-8221886912876606828.post-15787498181098083762020-11-21T17:24:00.001-08:002020-11-21T17:24:51.515-08:00Driving Cultural Change Through Software Choices<p> </p><figure class="fa rx ry rz sa gt" style="background-color: white; box-sizing: inherit; clear: both; color: rgba(0, 0, 0, 0.8); font-family: medium-content-sans-serif-font, -apple-system, system-ui, "Segoe UI", Roboto, Oxygen, Ubuntu, Cantarell, "Open Sans", "Helvetica Neue", sans-serif; margin: 56px 0px 0px;"><div class="gu z ae" style="box-sizing: inherit; margin: auto; position: relative;"><div class="xq gw z" style="box-sizing: inherit; height: 0px; padding-bottom: 314px;"><br class="Apple-interchange-newline" /><iframe allowfullscreen="" class="et kg eu ft w" frameborder="0" height="314" scrolling="auto" src="https://cdn.embedly.com/widgets/media.html?type=text%2Fhtml&key=a19fcc184b9711e1b4764040d3dc5c07&schema=twitter&url=https%3A//twitter.com/henryr/status/1329904368141778944&image=" style="box-sizing: inherit; height: 314px; left: 0px; position: absolute; top: 0px; width: 680px;" title="" width="680"></iframe></div></div></figure><br /><br />This tweet got me thinking about change, and how software engineers (and especially, Platform teams) can drive cultural change throughout companies.<br /><br />First, let’s take the question. You want to change the engineering values that your company is expressing. You don’t just want to create a heavyweight process (your checkin fails if you don’t reach X code coverage, for example), you want engineers to start to value these things enough that they don’t need a process to enforce them.<br /><br />I’ve driven and watched culture change happen enough times to know how to do it from the position of senior leadership. You change what you reward and focus on, and repeat that change enough that people will start to naturally change their perspective (or, sometimes, leave). If you go from putting all of your focus and attention on new projects and turn your prioritization to stability, taking the time to praise teams who improve their stability, promoting engineers who complete projects that are related to stabilization, and crucially, set prioritized goals for your teams to work on stability, your culture will change from prioritizing new projects to prioritizing stability.<br /><br />This is a powerful force, but it is slow, and what’s worse, it can have negative consequences. You don’t want teams who are afraid to do new things for fear that they will be punished for a lack of stability, for example. And if you overcorrect for a perceived cultural gap, you can end up chasing away otherwise great engineers who believe that their skills are no longer wanted or valued because they no longer have an important skill set. So trying to make your teams change their technology approaches purely via a cultural focus is not always the best approach.<br /><br />There is another lever that is available, however, particularly to platform developers. And that is the lever of product features.<br /><br />I’ve never met an engineer who didn’t occasionally copy-paste-modify some code. One of my earliest professional software lessons was that when you set up a codebase full of tests, other engineers are likely to write tests for their code because there will be lots of examples for how to test. This generalizes to the observation that people are most likely to take an existing thing and tweak it into a new thing that does what they need, and in the process they will take the good and bad from that existing thing. So if you want them to follow a best practice, put it in their starting templates.<br /><br />Take building a service. If you start with nothing but a system that runs a simple web server, you might go through the effort to also set up metrics and monitoring and healthchecks, but you might also feel like you’re busy and you just want to get the code that you absolutely must write done. On the other hand, when you start with a service framework that is already set up with metrics and monitoring and healthchecks, you’re more likely to do a little bit of work to make those at least mildly useful. This was one of the insights that Dropwizard gave me back in the day: pre-integration of stuff that you really need to run a service well means that your services are better from day one.<br /><br />Platform developers these days get this. Your infrastructure software now comes out of the box with observability hooks built in. We’re all probably more attuned to basics of creating reliable software now because our tools push it on us from the get-go, so there’s no cultural revolution necessary.<br /><br />We can go further than observability. Security can be a process, or a cultural value, but you can also go quite far by providing tools and platforms that have good security practices baked in to them, so that you’re not relying on the good citizenship of your development team. Testing is often hampered by the overhead of running tests, and investment into infrastructure that makes tests easy and fast to run is important to supporting a culture of software quality validation.<br /><br />All of this is to say that developers have more power than they imagine to change the engineering culture around them. As you build software that others will use or that your peers will work on, are you making it easy for them to do the right thing? If you build platforms, bake in easy integrations for the software values you want to see. If you’re in the position to choose new tools, pick ones that support the standards you want taken seriously. And as you write code, make it easy for others who will copy-paste what you’ve done to then do the right thing.Camille Fournierhttp://www.blogger.com/profile/05090020862261633248noreply@blogger.com0tag:blogger.com,1999:blog-8221886912876606828.post-88155293273747625702020-09-22T16:39:00.001-07:002020-09-22T16:39:21.497-07:00The Management Flywheel<section class="section section--body" name="fb16"><div class="section-divider"></div><div class="section-content"><div class="section-inner sectionLayout--insetColumn"><p class="graf graf--p" name="9274">Have you ever worked on a team that felt like it was just stuck in a rut? Somehow things were always just one fix away from improving: the next project, the next quarter, the next hire, this would turn the situation around. And yet these projects came, the quarters went by, new people were hired and joined and left and nothing ever really improved. It’s a sadly common situation, and one of the few that I believe can be laid squarely at the feet of the team’s manager.</p><figure class="graf graf--figure" name="04f7"><img class="graf-image" data-height="768" data-image-id="0*JAOAoT2dtTrg0lC7.jpg" data-width="1024" height="300" src="https://cdn-images-1.medium.com/max/1600/0*JAOAoT2dtTrg0lC7.jpg" width="400" /><figcaption class="imageCaption">Birmingham Museums Trust — Richard Trevithick’s 1802 steam locomotive with flywheel</figcaption></figure><p class="graf graf--p" name="2fa6">I’ve spent a lot of time over the past few years thinking about how you know whether a manager is great. When everything is going well, all a decent manager has to do is not screw things up, and it’s not always easy to tell on paper whether a manager is merely good or truly excellent. A person might have thorough training, they might have a large team, they might even have smart things to say on Twitter, but are they actually great at the job? None of these things will tell you the answer.</p><p class="graf graf--p" name="a6a2">But ask a manager about how they’ve gotten a team out of a rut, and now you start to hear about a real, common situation that a manager can make or break. There are some managers out there who just know how to take a team that is in a rut and turn them around. They may have different ways to describe their approach, but the outcome is the same: they start to turn the management flywheel.</p><p class="graf graf--p graf--startsWithDoubleQuote" name="03ca">“The Flywheel” is a popular startup analogy, and is best described in<a class="markup--anchor markup--p-anchor" data-href="https://www.jimcollins.com/concepts/the-flywheel.html" href="https://www.jimcollins.com/concepts/the-flywheel.html" rel="noopener" target="_blank"> this classic writeup.</a> The flywheel is heavy and painful to start, and starts off slow, but as it gathers momentum over time it goes faster and faster. Turning around a team feels like getting this flywheel spinning. Most managers who see a team in a rut can quickly detect many things that are going wrong. But it’s the response to these problems that distinguishes the great ones.</p><p class="graf graf--p" name="0e40">Some managers in this situation will proclaim that they are going to make big changes. Technical managers often see the flaws in the architecture or the legacy approaches to technology that the team is using, and immediately set about to overhaul the whole system. They want to change the language that the system is written in, or move to event-driven microservices, or rewrite the whole thing to run on Lambda so that there’s no support to worry about. Product-vision managers see that the product vision is lacking, and immediately paint a big picture for the team that articulates a beautiful world they could be providing for their customers. Talent-focused managers take one look at the people on the team and immediately decide that they are just the wrong people, and the only solution is to immediately overhaul the people and hire a bunch of “the right”** engineers to replace them.</p><p class="graf graf--p" name="db32">My experience is that most of these managers, in these situations, will fail. I have personally failed in all of these ways at least once in my career. But we won’t admit we failed. The technical managers will blame the legacy system and how impossible it is to rewrite the system while supporting the terrible decisions of the previous leaders. The product-vision managers will blame the team for not figuring out how to take their grand vision and turn it into a roadmap that makes sense. The talent-focused managers will somehow never manage to get the right team in place.</p><p class="graf graf--p" name="05f7">The managers who succeed in this may have big ideas about the technology, the product, and the talent and culture of the team, but they don’t just start with these ideas. Instead, they identify the little things that can be changed. Questions like “how do we decide what we’re working on today” and “do we have clear responsibilities for core tasks” start to get resolved. These managers may tackle confusing on-call schedules, or onerous project management expectations. The best will look across the projects and quickly re-prioritize work to gain focus for the team.</p><p class="graf graf--p" name="67b5">These little things start to build up steam. Now the team feels less burdened by unwieldy processes, and starts to make decisions faster. They know who is responsible for being on call, and stop swarming on every incident. They are working on fewer projects, and slowly start actually finishing those projects instead of dragging them out indefinitely.</p><p class="graf graf--p" name="3687">While this is happening, the team is getting happier, and the manager is learning more about the deeper challenges of the team. Is the product direction muddy? Is the team missing a critical set of skills that need to be hired? Does the entire architecture need to be revamped? These are critical questions to figure out and answer, but they are never the first questions that a manager over a team in a rut should be worrying about. There is inevitably a set of simple things that can be improved to get the team through this transition, to start building the flywheel that will make the big things easier. Because it’s easier to demand more of your product counterparts when the team is executing. It’s easier to hire when the team is engaged and excited to add new talent. And it’s much, much easier to fix a bad architecture when the team is able to ship changes.</p><p class="graf graf--p" name="d9c4">When you find yourself in a rut, remember that you don’t have to solve the root cause of everything wrong with the team as a first act. Start with the little problems. Give the team some small wins, clarity, and focus. Make their job a little bit easier, and help them work a little bit faster. Build up speed on the flywheel. Once you’ve gotten the team to be productive, they will still need you to set direction, and to resolve interpersonal and inter-team conflicts. They will need vision, mission, psychological safety, and inspirational goal-setting. But big things start small, so don’t forget to sweat the small stuff.</p><p class="graf graf--p" name="1f13"><em class="markup--em markup--p-em">** The right engineers range from “Engineers from the best colleges/FAANGs-only” to “only startup engineers who are hungry for an opportunity” to “only people who actually understand this industry” to “only people who appreciate my values” depending on the manager.</em></p></div></div></section><section class="section section--body" name="1031"><div class="section-divider"><hr class="section-divider" /></div><div class="section-content"><div class="section-inner sectionLayout--insetColumn"><p class="graf graf--p" name="e40f"><em class="markup--em markup--p-em">Thanks to Kelly Shortridge for feedback on this post.</em></p><p class="graf graf--p" name="e650"><em class="markup--em markup--p-em">Enjoy this post? You might like my book, </em><a class="markup--anchor markup--p-anchor" data-href="http://amzn.to/2nw1QN5" href="http://amzn.to/2nw1QN5" rel="noopener nofollow noopener noopener" target="_blank"><em class="markup--em markup--p-em">The Manager’s Path</em></a><em class="markup--em markup--p-em">, available on Amazon and Safari Online!</em></p></div></div></section>Camille Fournierhttp://www.blogger.com/profile/05090020862261633248noreply@blogger.com0tag:blogger.com,1999:blog-8221886912876606828.post-7774937324317862752020-05-09T13:09:00.000-07:002020-05-09T13:09:46.814-07:00Product for Internal PlatformsFor the past 3 years, I have been running a platform engineering organization. Since that term is vague, where I work it means the software side of infrastructure. Compute platforms like kubernetes, storage systems, software development tools, and frameworks for services are part of the mandate. Our customers are other engineers at the company.<br />
<br />
I also oversee the product team for this area. Now, I’m not a product manager (which I’ll shorten to PM for the rest of this post, not to be confused with project manager), and I rely on my PM team heavily for their expertise. But that doesn’t mean that I can personally neglect the product side, and indeed I spend a lot of time thinking about the products and strategy for my org as part of my day-to-day work.<br />
<br />
These are some things I’ve observed and learned in this process. I share them with you because I think many folks in platform-type teams, especially engineers and those of you on platform teams without formal product managers, might benefit from understanding how to approach these problems.<br />
<br />
<h2>
What’s so hard about product for (internal) platform?</h2>
<h3>
Customer Group Size</h3>
Platform product decision-making is something of a unique discipline. When many people think about product managers, the image that springs to mind is a product manager for large consumer-facing products. Metrics, metrics, metrics! A/B tests and user studies and KPIs and design sprints and revenue models. I’m sure that any time you are building products for a large user base, this is a factor, and PMs for AWS probably have a lot of metrics to guide them. But A/B testing for an audience of hundreds doesn’t usually teach you much. When you’re building platform for internal customers at a small-to-midsized company, a metrics-driven strategy is harder to apply.<br />
<br />
<h3>
Captive Audience</h3>
Not only do we have a small group of customers, we have a captive audience. Other teams can and sometimes do decide to go off on their own and build their own platforms, but for many types of products, we provide the only option. You can ask customers what they want or how they like your products, but they may not want to complain to their colleagues. Of course, platform products also suffer from the problem that some engineers always think they could build something better, if only they had the time, so you also have a customer segment that seems to never be satisfied no matter how hard you work.<br />
<br />
A captive audience leads us to believe that basic metrics for customer adoption are not interesting, which in turn leads us to ignore them, sometimes to our peril. Many platform teams end up with several overlapping half-finished products because they assumed a captive audience would lead to product success.<br />
<br />
<h3>
It’s Hard To Think Like Your Customer</h3>
Finally, there is the universal challenge of platforms. Good software products for engineers tend to come from someone with a clear problem in front of them, who built specifically to solve that problem. They are intimately familiar with the customer because they are the customer. They are building for one person or one team, and they can clearly see what needs to be solved. But the platform team doesn’t build solutions for only one user. The whole value of a platform team is providing broadly-useful systems, so we are rarely presented with a well-specified need to fill.<br />
<br />
When you are on a platform team, it is easy to lose the feel for what it is like to use your own products, because you are deep in the details. You spend your day living and breathing the ins and outs of git, and your users know the 3 commands they have to memorize and otherwise rely on ohshitgit to get themselves out of trouble. In a perfect world, platform product managers are regularly using the products they support in order to identify pain points and gaps that engineers might miss and users may not complain about. In the real world it’s hard to find time to use your products in anger when you are also dealing with all the other parts of the PM job.<br />
<br />
You can observe this dilution of focus and quality in a lot of open source platform products that are created by big companies in order to sell you on their cloud solution or to create an industry standard. It starts look like software that is building to be built. And you absolutely see it in internal platform projects at companies big and small. When platform teams build to be building, especially when they have grand visions of complex end goals with few intermediary states, you end up with products that are confusing, overengineered, and far from beloved.<br />
<br />
<h2>
So how do you solve this?</h2>
If the challenges can be summed up as: a small, captive audience, that is hard to truly empathize with, and a tendency to build thoughtlessly, what can you do? Here are a few approaches I’ve found to help:<br />
<br />
<h3>
Assimilate and Expand</h3>
You don’t have a huge customer base to test things on, so how do you find a successful product? Don’t be ashamed to take over a system from a team that built it with themselves in mind, if that system seems to be the right general concept for the wider company. A lot of platform teams don’t like doing this, because they think that it means they will have to live with decisions that they don’t agree with. They forget that when you take a product from a team that built it, you already have a reasonably satisfied customer to start with! For better or worse, someone showed that they had a problem, and they solved it, and you wouldn’t be taking it over if you didn’t think this problem was worth solving in a holistic fashion, right?<br />
<br />
I did this when I built a global service discovery solution long ago. Another team had first identified the problem and created their own version of a solution using ZooKeeper. The solution was fine for their needs, but didn’t solve the general needs of everyone at the company for global scaling. So I took over the idea of the project, and turned it into true platform infrastructure, built for a big company and not just one team therein. There were plenty of product decisions to make as part of that work, but the core identification of the problem as worth solving was done for me. There is a lot of interesting work in taking a solution that is locally-optimized and turning it into something that can be used by a diverse set of applications.<br />
<br />
<h3>
Partner to Prototype</h3>
Another way to identify promising new opportunities is to partner with another team, and even embed someone into that team, to understand a problem better. Partner teams are likely to come by and ask if you are planning to build something to solve their various problems. When you believe that this is a good specific example of something that will become a general pattern, take advantage of this request to learn more! In fitting with the goal of really understanding the feel of a problem, having platform engineers build an application with a prototype idea for a platform within it, then using the lessons from that project to extract a more general system, is a productive way to quickly iterate an idea into something that is usable. After all, the hardest part of the product side of platform engineering is figuring out usability. Want to know how people will actually write code around this offering? Well, writing code around the offering yourself is a good way to figure that out.<br />
<br />
<h3>
Make a Migration Strategy Early</h3>
In platform teams a lot of the product job is figuring out how to make open source products or popular strategies work for your company. Take kubernetes. The product challenges around internal kubernetes are in the decisions you make on how to integrate it into the existing ecosystem in order to get people to adopt it without too much argument. If you are a company of a certain age, you may already have an old private cloud solution running around. Everyone is used to running on VMs, but you think kubernetes will give you some operational improvements and also encourage the company to start to rethink its software practices to be a bit more modern.<br />
<br />
That is all well and good, but the product work is not “tell everyone you have kubernetes now and they have to use it.” Instead, the product work is to identify different types of customers and figure out what will make it easy for them to migrate. What are the carrots you can provide to get people to do work that they don’t care about doing? Perhaps the carrots are efficiencies in getting access to compute or storage. Perhaps you can offer a higher SLO with the new product. Perhaps it is faster, more secure. But these things don’t just happen. You have to choose which features you are highlighting to your customers, you have to help them understand the offering and advantages, and you have to deliver on those promises.<br />
<br />
Despite having captive audiences, platform teams are notorious for creating half-finished product offerings that somehow fail to get adopted. When your platform organization is running three different generations of solutions to the same problem with no clear plan to remove any of them, and your customers are both confused by the offerings and dissatisfied with them, you have a serious product failure on your hands. The migration strategy must be a primary part of the product planning.<br />
<br />
<h3>
You Aren’t Google, So Don’t Build When You Don’t Have To</h3>
My final piece of product advice to platform teams is to remember that you aren’t Google (unless you are, in which case, hi!). When you have a platform team of 7, or even 100, you must be extremely thoughtful about what you choose to build. Platform teams of all sizes can get bogged down trying to imitate systems that have been built up over years at big companies. Even when those big companies provide their solutions as open source software, they often encode all kinds of assumptions about the surrounding ecosystem of available products and the culture and needs of the engineers using the product that may not work well in your company. It is not good product management to say “Google does it, therefore we should.”<br />
<br />
Instead, start with a clear understanding of the problem, and an accounting of your existing ecosystem and culture, before diving into a technical solution. Your data volume is out of control. You might need to solve this with a better storage solution, or you might need to solve it by identifying the top data producers, and asking whether the data they’re storing is actually valuable. You’ll often find that the data is garbage, or the developers can change their workflow, or a little bit of query performance tuning makes this application scale just fine in a normal RDBMS. Only build when you have exhausted the alternatives.<br />
<br />
<h2>
Summing Up</h2>
Great platform teams can tell a story about what they have built, what they are building, and why these products make the overall engineering team more effective. They have strong partner relationships that drive the evolution of the platform with focused offerings that meet and anticipate future needs of the rest of the company. They are admired as strong engineers who build what is needed, to high standards, and they are able to invest the time to do that because they don’t overbuild.<br />
<br />
Whether you are a platform engineer, engineering manager, or PM, it pays to remember that you still need to be customer-focused and strategic about your platform offerings. Without a clear strategy for showing impact and value, you end up overlooked and understaffed, and no amount of cool new technology will solve that problem.<br />
<br />
Thanks to my darling product and platform friends for their feedback on drafts, especially Renee and Pete.<br />
<br />
Enjoy this post? You might like my book, <a href="http://amzn.to/2nw1QN5">The Manager’s Path</a>, available on Amazon and Safari Online!Camille Fournierhttp://www.blogger.com/profile/05090020862261633248noreply@blogger.com0tag:blogger.com,1999:blog-8221886912876606828.post-30093489796985238392019-05-12T10:56:00.000-07:002019-05-12T10:56:31.511-07:00OPP (Other People's Problems)<div class="graf graf--p" name="5e72">
A hard lesson for me over the past several years of my career has been figuring out how to pick my battles. I’ve seen many friends and colleagues struggle with this as well: how do you know when to involve yourself in something, and how do you know when to stay out of it? How do you figure out where the line is?</div>
<div class="graf graf--p" name="5e72">
<br /></div>
<h3>
The setup</h3>
<div class="graf graf--p" name="4a65">
If you’re reading this looking for advice, you’re probably a go-getter. You consider yourself a responsible person, who cares deeply about doing things right. Your care may be focused on software and systems, or on people and organizations, or on processes and policies, or all of the above.</div>
<div class="graf graf--p" name="97dd">
<br /></div>
<div class="graf graf--p" name="97dd">
This attitude has probably served you well in your career, especially those of you who have been working for a number of years. You’ve been described as having a “strong sense of ownership,” and people admire your ability to think broadly about problems. You try to think about the whole system around a problem, and that helps you come up with robust solutions that address the real challenges and not just the symptoms.</div>
<div class="graf graf--p" name="e8b1">
<br /></div>
<div class="graf graf--p" name="e8b1">
And yet, despite these strengths, you’re often frustrated. You see so many problems, and when you identify those problems, people sometimes get mad. They don’t take your feedback well. They don’t want to let you help fix the situation. Your peers rebuff you, your manager doesn’t listen to you, your manager’s manager nods sympathetically and then proceeds to do nothing about it.</div>
<div class="graf graf--p" name="5626">
<br /></div>
<div class="graf graf--p" name="5626">
That kind of grinding frustration can wear you down over time. I know, because I’ve been there. I left a cushy big company job because I saw too many things I felt powerless to fix. When I got into management, I figured that I would have the power to make things right. Then I thought that when I became the leader of all of engineering I could do it. Then I thought that when I became an executive I would be able to do it. Chasing that dream of being able to fix all the things contributed to me feeling exhausted, and dare I say a bit burned out, when I finally decided to leave my CTO gig.</div>
<h3>
<br /></h3>
<h3>
Escaping the Trap</h3>
<div class="graf graf--p" name="94ab">
I’ve come to realize that there isn’t a job where you can fix all the things. It is true that founders have immense ability to set direction and culture, but trying to control everything happening in a company causes many other problems that are outside of the scope of this essay. Assuming that you are not a founder, you should just take a minute to really let it sink in: there is no place you can go where you can control everything and fix all the problems, no matter how much you get promoted. There’s always going to be something you can’t fix.</div>
<div class="graf graf--p" name="83ed">
<br /></div>
<div class="graf graf--p" name="83ed">
So how do you decide where to exert your energy?</div>
<div class="graf graf--p" name="3b14">
<strong class="markup--strong markup--p-strong"><br /></strong></div>
<div class="graf graf--p" name="3b14">
<strong class="markup--strong markup--p-strong">Step one: Figure out who owns this problem</strong></div>
<div class="graf graf--p" name="a051">
<br /></div>
<div class="graf graf--p" name="a051">
If it’s your job (or the job of someone who reports to you), great. Go to it! Tend your own garden first. Make systems that are as robust as you believe systems should be. Follow processes that you believe are effective and efficient. If you are not leading by example, you have to start there. Stop reading now and go fix the things!</div>
<div class="graf graf--p" name="fe38">
<br /></div>
<div class="graf graf--p" name="fe38">
If there’s no clear owner, do you know why? Is it just because no one has gotten around to doing it, or has the organization specifically decided not to do it? If no one’s gotten around to doing it, can you do it yourself? Can your org do it, just within your org?</div>
<div class="graf graf--p" name="5ce3">
<br /></div>
<div class="graf graf--p" name="5ce3">
If it’s someone else’s job, how much does it affect your day to day life? Does it bother you because they’re <em class="markup--em markup--p-em">doing it wrong</em>, or does it actually, really, significantly make it harder for you to do your job? Really? That significantly? There’s no work around at all? If it is not directly affecting your job, drop it!</div>
<div class="graf graf--p" name="d0fd">
<strong class="markup--strong markup--p-strong"><br /></strong></div>
<div class="graf graf--p" name="d0fd">
<strong class="markup--strong markup--p-strong">Step two: Talk to all the people</strong></div>
<div class="graf graf--p" name="4398">
<br /></div>
<div class="graf graf--p" name="4398">
If you don’t clearly own the problem, you need to talk to people. If you feel tired by the idea of talking to all people, stop! This is a sign that you should not pick this battle! It’s already draining you and you haven’t even started on the path to addressing it. It is probably a good idea to just try to let it go, or at best, tell your manager that you worried about whatever it is, and then let it go.</div>
<div class="graf graf--p" name="a513">
<br /></div>
<div class="graf graf--p" name="a513">
If you’re ok with talking to all the people, then get out there and get a sense of the problem beyond you and your team. You can do this formally, with a document that you prepare addressing the problem as you see it, or informally, as a series of user interviews. You will need this information to make a case to fix it, and to make a plan for how to fix it. Does the information you’ve gathered from others make you think that perhaps this problem really isn’t as important as you first thought it was? Is someone else already solving this problem? Great! Let it go!</div>
<div class="graf graf--p" name="a933">
<br /></div>
<div class="graf graf--p" name="a933">
If you know who should own this, you need to give them a chance to fix it. Which means you need to come with examples of how the problem is impacting you or your team. Missing those examples? Stop! This is not your problem to fix! Don’t go bringing problems based on people from other teams complaining to you. Those teams need to bring up the problems themselves. If you must, tell their manager that you’re hearing these complaints, and let that manager decide whether to deal with it.</div>
<div class="graf graf--p" name="7337">
<strong class="markup--strong markup--p-strong"><br /></strong></div>
<div class="graf graf--p" name="7337">
<strong class="markup--strong markup--p-strong">Step three: Plan the fix</strong></div>
<div class="graf graf--p" name="8e05">
<br /></div>
<div class="graf graf--p" name="8e05">
Ok so you talked to all the people and the problem is still not fixed. Assuming no one owns the problem and you really still want to own it and fix it, great. Make a concrete plan for how you will fix it, and share that plan with the people who need to know about it. You should expect that you will need to get feedback and revise your plan, and the amount of feedback and revision required will be directly related to how big the problem is, how many people it impacts, and how controversial the fix you’re proposing is. Expect this feedback, buy-in, and revision process to take a while. You’ll need feedback from all corners, friends are good to start with but be sure to include your skeptics too. Your goal is to convince everyone that they want you to solve the problem. Yes, that means a lot more talking. If you’re tired now, maybe this isn’t your problem to solve!</div>
<div class="graf graf--p" name="a535">
<br /></div>
<div class="graf graf--p" name="a535">
If this problem is with another team, and you talked to that team, brought them clear examples of why it is truly a big deal, and they haven’t answered your concerns to your satisfaction, you have a choice. Do you escalate to your manager? If you have clear examples of why it’s a problem, and your peer hasn’t been able to do anything, this is a perfectly fine time to escalate! Consider though whether you can negotiate a fix with the other team, or work around the other team. And, especially when the problem is cultural, consider whether you really need to make this problem into a big deal, or whether you can just let it go.</div>
<div class="graf graf--p" name="c825">
<strong class="markup--strong markup--p-strong"><br /></strong></div>
<div class="graf graf--p" name="c825">
<strong class="markup--strong markup--p-strong">Step four: Enact the plan</strong></div>
<div class="graf graf--p" name="3bdb">
<br /></div>
<div class="graf graf--p" name="3bdb">
And now we get to the tricky part. You saw this problem, you complained about it, you made it your own, and now you have to fix it! This is what you wanted, right?</div>
<div class="graf graf--p" name="4dd3">
<br /></div>
<div class="graf graf--p" name="4dd3">
Unfortunately, the fix will almost certainly take a lot longer than you’re thinking it will take, and it will probably be a lot of work on your part to see it all the way through. And by the way, it’s unlikely that you get to give up any of your other problems to take this one on. But this is something you feel passionately about, and that should make the extra work worth it to you.</div>
<div class="graf graf--p" name="2256">
<strong class="markup--strong markup--p-strong"><br /></strong></div>
<div class="graf graf--p" name="2256">
<strong class="markup--strong markup--p-strong">Step five: Think about how many of these you can actually do</strong></div>
<div class="graf graf--p" name="cc1d">
<br /></div>
<div class="graf graf--p" name="cc1d">
Good job! You fixed the problem! It was probably a little bit harder to fix than you expected huh? Especially if it was a cultural thing that you needed to change. But it should feel good to have it fixed. You can see the improvement you were aiming for, and you’ve got a great story to tell.</div>
<div class="graf graf--p" name="0775">
<br /></div>
<div class="graf graf--p" name="0775">
Take a moment to reflect on whether it was worth the effort to you, and think about how many more things like this you see at the company you’re in that you really want to change just as much as that one.</div>
<div class="graf graf--p" name="0f63">
<br /></div>
<div class="graf graf--p" name="0f63">
Think about what else you could be doing with that extra energy. Finishing a critical project sooner? Hiring a few people who are more in tune with your way of doing things, who might be able to fix things for you? Writing a novel? Getting a personal best on your deadlift?</div>
<h3>
<br /></h3>
<h3>
Pick Your Culture First and Foremost</h3>
<div class="graf graf--p" name="043a">
Learning how to pick your battles is also about learning how to pick your company and pick your boss, because your job really shouldn’t be all or even mostly about battles. Going through this exercise of solving an unowned problem is fun once in a while, but it’s a real drag when you feel like you’re surrounded by such problems, you can’t ignore them, and you’re powerless to fix them. That is a good sign that it’s time to find a new job, preferably somewhere that is more in tune with your way of doing things. Life is so much more fun when you have people around you that you trust to solve problems, even the problems you have a lot of opinions about.</div>
<div class="graf graf--p" name="043a">
<br /></div>
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><img height="640" src="https://cdn-images-1.medium.com/max/1600/1*ooyoTtGkEfUYosK56_AWdw.jpeg" style="margin-left: auto; margin-right: auto;" width="507" /></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Flowchart courtesy twitter user <a class="markup--anchor markup--p-anchor" data-href="https://twitter.com/felidelg" href="https://twitter.com/felidelg" rel="noopener" style="font-size: 12.8px;" target="_blank">https://twitter.com/felidelg</a><br /></td></tr>
</tbody></table>
<div class="graf graf--p" name="7c83">
<em class="markup--em markup--p-em">Enjoy this post? You might like my book, </em><a class="markup--anchor markup--p-anchor" data-href="http://amzn.to/2nw1QN5" href="http://amzn.to/2nw1QN5" rel="nofollow noopener nofollow noopener nofollow noopener noopener noopener" target="_blank"><em class="markup--em markup--p-em">The Manager’s Path</em></a><em class="markup--em markup--p-em">, available on Amazon and Safari Online!</em></div>
Camille Fournierhttp://www.blogger.com/profile/05090020862261633248noreply@blogger.com0tag:blogger.com,1999:blog-8221886912876606828.post-88371110635116287052018-11-23T07:49:00.001-08:002018-11-23T07:49:44.076-08:00I hate manager READMEs<br />
<section class="section section--body" name="301e"><div class="section-divider">
</div>
<div class="section-content">
<div class="section-inner sectionLayout--insetColumn">
<div class="graf graf--p" name="28c6">
I got feisty on twitter this week and wrote up some tweets on manager READMEs, a recent hot trend in management. Let’s break them down:</div>
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi5FUXR2pmzolNcvCCBbrtU6npAg09Hc15L2718nK4QP3yQPIiOGOtDpLt_8xF9s4D88DzSRJKRgQX6E_iZJsl3pT3NSWsF4VBfi-eDcAHvU1r_fPy_E2TUt_oOmc00aR-Fx8g3kOrn-0E/s1600/Screen+Shot+2018-11-23+at+10.39.21+AM.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="296" data-original-width="1006" height="187" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi5FUXR2pmzolNcvCCBbrtU6npAg09Hc15L2718nK4QP3yQPIiOGOtDpLt_8xF9s4D88DzSRJKRgQX6E_iZJsl3pT3NSWsF4VBfi-eDcAHvU1r_fPy_E2TUt_oOmc00aR-Fx8g3kOrn-0E/s640/Screen+Shot+2018-11-23+at+10.39.21+AM.png" width="640" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Dropping f-bombs is one of my "quirks"</td></tr>
</tbody></table>
<br />
<figure class="graf graf--figure graf--iframe" name="44db"><figcaption class="imageCaption"><br /></figcaption></figure><br />
<div class="graf graf--p" name="b206">
Well, what can I say, I’m sick of this trend. I’ve been a skeptic from day one, but what pushed me over the edge was watching one of my senior engineer friends react to <a class="markup--anchor markup--p-anchor" data-href="https://firstround.com/review/the-indispensable-document-for-the-modern-manager/" href="https://firstround.com/review/the-indispensable-document-for-the-modern-manager/" rel="noopener" target="_blank">this article on the concept</a>. It mirrored the loathing I’ve heard from several senior engineers as well as the general negative reaction most managers in my trusted circle have about the concept. But we’ve got a lot of people trying to popularize the idea, so enough’s enough, and today I’m willing to be the critic to this well-intended exercise.</div>
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj-C6mzVYf15leLWgr1wTBhhCCCwqUmncCE-WXXhdrzHcuXJ1Yd_65JnKb1z5_KbMlbtqR4RWq8lfzclks_XpXkK28Xo0uL0f4K8NzNW7H8AzAn7Wzvp3rxGIv1kp-Nq6siS9BNxPbjO7w/s1600/Screen+Shot+2018-11-23+at+10.40.30+AM.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="432" data-original-width="1000" height="275" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj-C6mzVYf15leLWgr1wTBhhCCCwqUmncCE-WXXhdrzHcuXJ1Yd_65JnKb1z5_KbMlbtqR4RWq8lfzclks_XpXkK28Xo0uL0f4K8NzNW7H8AzAn7Wzvp3rxGIv1kp-Nq6siS9BNxPbjO7w/s640/Screen+Shot+2018-11-23+at+10.40.30+AM.png" width="640" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">I will always tell it to you straight whether you like it or not, except when doing so will open me up to excessive criticism or otherwise rock the boat too much, and then I’ll probably just roll my eyes behind your back</td></tr>
</tbody></table>
<br />
<figure class="graf graf--figure graf--iframe" name="0642"><figcaption class="imageCaption"><br /></figcaption></figure><br />
<div class="graf graf--p" name="0339">
Look, fellow managers: there is <strong class="markup--strong markup--p-strong">no way</strong> to write these and not be self-serving. You are writing them presumably to shortcut problems that arise when people misunderstand your behavior or when they act in a way you don’t like or otherwise violate some expectations that you believe are within your rights to set. And hey, I’m a boss too, I get it. You want people to respond to your emails within a certain timeframe, fine, that’s (maybe) a reasonable expectation. If most of the manager READMEs were essentially descriptions of what behaviors you expect from your direct reports in the performance of their job, I might not mind so much. It’s a bit crass (sounds more appropriate for a manager of a factory floor than a manager of “knowledge workers”), but could be effective.</div>
<div class="graf graf--p" name="0f1f">
But then there’s this idea that you can build trust with this exercise, and you do that by being brutally honest about your own flaws, your values, and the behaviors they should expect from you. That is where I really take issue with this process.</div>
<div class="graf graf--p" name="0f1f">
<br /></div>
<div class="graf graf--p" name="8488">
First of all, be real: you probably do not know yourself as well as you think you know yourself. It’s the Dunning-Kruger of self-awareness. If you’ve gone through any deep coaching, self-awareness practice, or therapy, what you learn over time is how hard it is to be 100% honest about yourself and your motivations. If you’ve gone through very little of that, well, you are almost certainly in deep denial about your behaviors and how well they actually reflect your conscious beliefs. I know myself well enough to know that I might usually behave in alignment with certain personal values and expectations, but I will break that alignment at the worst possible times (you’re most likely to break with your best intentions in times of high stress).</div>
<div class="graf graf--p" name="8488">
<br /></div>
<div class="graf graf--p" name="18ae">
What happens when you put out this declaration of vulnerability and earnestness and self-awareness and then you behave in such a way as to completely contradict the thing you claimed to be? You damage your credibility, hard. You damage the trust you might otherwise have built with your team. And you make it harder for people to call you on your hypocrisy, because they know that you don’t actually see yourself this way. It is incredibly difficult to tell someone that the thing they believe about themselves enough to publicly declare is, in fact, not true. It’s hard to tell your partner that, it’s hard to tell your friends that, and it’s basically impossible to tell your boss.</div>
<div class="graf graf--p" name="18ae">
<br /></div>
<div class="graf graf--p" name="3986">
Yes, of course, you said that you want feedback, that you respond well to feedback. That does not actually change the fact that you have a huge power differential to the person who reports to you. I like to think that I respond well to feedback, and I ask for it from people throughout my tree. I don’t actually expect them to believe me about that, because I’ve had too many managers who claimed they wanted feedback and then reacted to my honest feedback by shutting me down, blaming me or others, or otherwise making it clear that maybe they do want <em class="markup--em markup--p-em">some</em> feedback, <em class="markup--em markup--p-em">sometimes</em>, but not <em class="markup--em markup--p-em">this </em>feedback, not at <em class="markup--em markup--p-em">this </em>time, not in <em class="markup--em markup--p-em">this </em>way.</div>
<div class="graf graf--p" name="3986">
<br /></div>
<div class="graf graf--p" name="3ced">
If you want to build trust, you do that by showing up, talking to your team both individually and as a team, and behaving in an ethical, reliable manner. Over, and over, and over again. You don’t get it from writing a doc about how you deserve their trust.</div>
<div class="graf graf--p" name="3ced">
<br /></div>
<div class="graf graf--p" name="81a7">
One of the worst parts of these docs is the airing of your own perceived personality faults. <em class="markup--em markup--p-em">I suck at niceties. I get heated sometimes in discussions. I don’t give praise very much. </em>If you know you have foibles/quirks that you in fact want to change about yourself, <em class="markup--em markup--p-em">do the work. </em>Don’t put them out there for your team to praise you for the intention to do the work, just do it. And while you get to decide which of your foibles/quirks/challenges you will or will not change about yourself, as the manager, it is on you to make your team effective and that may in fact mean changing some things about yourself that you don’t want to change. Writing them down feels good, like you’ve been honest and vulnerable and no one can be surprised when you behave badly, after all you warned them! But it does not excuse these bad behaviors, and it certainly does not take the sting away when someone feels shut down by your rudeness or unhappy from a lack of positive feedback. If you must write a README, please skip this section. Keep your bad behaviors to yourself, and hold yourself accountable for their impact.</div>
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg3BZeyi06BLI6Sf5XBEMkQPMozrJ5sCrOZ2fpCrUWjHHHQYFpXgMV4W06PkydPtGnVU2K797dt0pTM25b9EHNlLXrSUisrty4qBtVTw9IQRYCECtfZHyfjdhzH2Yy-eCoxMpUMtzkNk70/s1600/Screen+Shot+2018-11-23+at+10.40.59+AM.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="432" data-original-width="1002" height="273" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg3BZeyi06BLI6Sf5XBEMkQPMozrJ5sCrOZ2fpCrUWjHHHQYFpXgMV4W06PkydPtGnVU2K797dt0pTM25b9EHNlLXrSUisrty4qBtVTw9IQRYCECtfZHyfjdhzH2Yy-eCoxMpUMtzkNk70/s640/Screen+Shot+2018-11-23+at+10.40.59+AM.png" width="640" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">I care about you and want you to feel seen but also I want to not come off as a total opinionated bitch when someone inevitably disagrees with me</td></tr>
</tbody></table>
<div class="graf graf--p" name="81a7">
<br /></div>
<br />
<figure class="graf graf--figure graf--iframe" name="2e1e"><figcaption class="imageCaption"><br /></figcaption></figure><br />
<div class="graf graf--p" name="0d34">
I believe many people who are doing this are really trying to do the right thing. I see your good intentions. But good intentions don’t just magically make bad ideas turn good. Everyone writing one of these is trying to make it easier for their teams to work for them. But the unintended consequences of these docs given the power differential between you and the people on your team are real and serious. Recognizing that you are human and have flaws and preferences is great! But trying to codify them into a README is folly because for everything you know about yourself there’s another thing you don’t know, and your documentation is out of date the minute you write it down. You’re not a computer.</div>
<br />
<figure class="graf graf--figure graf--iframe" name="34eb"><div class="aspectRatioPlaceholder is-locked">
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgF684YxqaOAkyFTdwjzkX7SEmu5hwJueCTsF3sGzQt71kubPqsITj5wViQteUBeLHVMalrAD1rE-EeGzNTiwS47htOQKJ10TV43cCpd2Fayuj6bZpssTXx1or1uQ0H9AmuSDRVP0gGRzw/s1600/Screen+Shot+2018-11-23+at+10.41.48+AM.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="474" data-original-width="1002" height="300" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgF684YxqaOAkyFTdwjzkX7SEmu5hwJueCTsF3sGzQt71kubPqsITj5wViQteUBeLHVMalrAD1rE-EeGzNTiwS47htOQKJ10TV43cCpd2Fayuj6bZpssTXx1or1uQ0H9AmuSDRVP0gGRzw/s640/Screen+Shot+2018-11-23+at+10.41.48+AM.png" width="640" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">I've gotten a LOT of coaching</td></tr>
</tbody></table>
<div class="iframeContainer">
<br /></div>
</div>
</figure><br />
<div class="graf graf--p" name="ed38">
You know where these kinds of docs <strong class="markup--strong markup--p-strong">are </strong>useful? As a coaching, therapy, or personal introspection exercise! I love doing stuff like this for myself. It’s great to spend time writing down things that you believe about yourself. But the thing is, to make that process really useful, you then need someone who helps you dig into which of the things you believe about yourself are really true, and which are stories you’re telling yourself. You need a person who is in a position to hold you accountable when you stray from those stated values, or who can help you refine them better as you learn more about yourself. And that person is not someone who reports to you. That person may only be yourself, or maybe it’s a coach, or a therapist. I wouldn’t even really recommend trying to make your own manager do this job, because it’s probably not something they’re trained to do.</div>
<div class="graf graf--p" name="ed38">
<br /></div>
</div>
</div>
</section><section class="section section--body" name="7bbd"><div class="section-divider">
<br />
<hr class="section-divider" />
</div>
<div class="section-content">
<div class="section-inner sectionLayout--insetColumn">
<div class="graf graf--p" name="528b">
So maybe I’ve convinced you, and maybe I haven’t. If none of my arguments so far have convinced you not to write these for the purpose of sharing with your team, perhaps my final words will:</div>
<blockquote class="graf graf--pullquote" name="ab83">
<h2>
<em class="markup--em markup--pullquote-em">You’re probably just wasting your time, because no one reads the docs anyway!</em></h2>
</blockquote>
<div class="graf graf--p" name="45cc">
<em class="markup--em markup--p-em"><br /></em></div>
<div class="graf graf--p" name="45cc">
<em class="markup--em markup--p-em">If you’d rather read something funny, check out Tim’s parody, </em><a class="markup--anchor markup--p-anchor" data-href="https://medium.com/@arthegall/a-user-guide-from-my-five-year-old-2b0793fe4cff" href="https://medium.com/@arthegall/a-user-guide-from-my-five-year-old-2b0793fe4cff" target="_blank"><em class="markup--em markup--p-em">“A User Guide from My 5-year-old”</em></a></div>
<div class="graf graf--p" name="01f1">
<em class="markup--em markup--p-em"><br /></em></div>
<div class="graf graf--p" name="01f1">
<em class="markup--em markup--p-em">Enjoy this post (or hate it)? You (still) might like my book, </em><a class="markup--anchor markup--p-anchor" data-href="http://amzn.to/2nw1QN5" href="http://amzn.to/2nw1QN5" rel="nofollow noopener nofollow noopener noopener noopener" target="_blank"><em class="markup--em markup--p-em">The Manager’s Path</em></a><em class="markup--em markup--p-em">, available on Amazon and Safari Online!</em></div>
</div>
</div>
</section>Camille Fournierhttp://www.blogger.com/profile/05090020862261633248noreply@blogger.com0tag:blogger.com,1999:blog-8221886912876606828.post-74697176114689675832018-11-17T09:23:00.003-08:002018-11-17T09:23:52.100-08:00When is someone ready to manage managers?<div class="graf graf--p" name="3453">
When I wrote “<a class="markup--anchor markup--p-anchor" data-href="https://amzn.to/2Dr2rXY" href="https://amzn.to/2Dr2rXY" rel="noopener" target="_blank">The Manager’s Path</a>” I talked about what it means to work at the various levels of leadership, but I didn’t really talk as much about how you actually climb to those levels. For some people, it just happens as a consequence of being in a growing organization, and succeeding at growing with that organization. But how does that work, really? And how can you show that you are ready to take on bigger things when the opportunity comes along?</div>
<div class="graf graf--p" name="933f">
<br /></div>
<div class="graf graf--p" name="933f">
First, <strong class="markup--strong markup--p-strong">look at the role you are currently playing. </strong>If you are still spending most of your time deep in the technical details of the projects, you are probably not really working on the skills needed to manage managers. You need to develop the ability to leverage your attention and time through more people and projects, and that generally requires that you start looking outward (at people, teams, and related projects) and forward (to identifying opportunities, strategies, and potential pitfalls), rather than deeply down into the technical details. Be honest with yourself: Are you ready to spend less time in the technical details? If not, you are probably not going to enjoy managing managers. Is your team set up for you to spend less time in the details? If not, you need to fix that problem by developing new technical leaders, before you are likely to be tapped to manage more people and eventually managers.</div>
<div class="graf graf--p" name="51fa">
<br /></div>
<div class="graf graf--p" name="51fa">
Once you’ve started to scale yourself beyond a tech lead who manages a few people, you’re ready to be considered for the next level.<br />
<br /></div>
<h3 class="graf graf--h3" name="9390">
How to go from line manager to managing managers</h3>
<div class="graf graf--p" name="fb13">
The promotion path forward generally depends on a few things.</div>
<div class="graf graf--p" name="f44f">
<strong class="markup--strong markup--p-strong"><br /></strong></div>
<div class="graf graf--p" name="f44f">
<strong class="markup--strong markup--p-strong">Can you scale your team effectively?</strong> If the team is 5 people growing to 20, it’s easy to argue that there is a need to create sub-teams. If you are seen as instrumental to leading the growth, hiring the new people, making sure the new hires are on-boarding successfully, and helping the team scale effectively, it might be you who gets called upon to manage the new team!</div>
<div class="graf graf--p" name="af03">
<br />
However, this only works when you are scaling successfully as a manger. Most of us want to promote from within, but when your team isn’t running effectively, it doesn’t make us want to give you more. This is usually what’s happening when a division grows quickly and the original manager does not get tapped to run the division. There’s a lack of confidence in the original manager to lead the larger team. If those new hires aren’t effectively working, if people are complaining to your manager that they feel unhappy with the work, if your projects aren’t shipping, if you have a lot of quality problems, or even if you just can’t effectively juggle all of the work of managing people and projects, you’re probably seen as unable to succeed at the next level of management.</div>
<div class="graf graf--p" name="aa85">
<strong class="markup--strong markup--p-strong"><br /></strong></div>
<div class="graf graf--p" name="aa85">
<strong class="markup--strong markup--p-strong">Would other managers want to work for you? </strong>You need to be able to balance people and projects and getting things done, but that’s not all. The second question that arises is: would other managers want to work for you? Managers want a boss who can teach us things. We want coaching on how to be better, without being micromanaged. We want room to make our own decisions and our own mistakes. And we want to work for people who we trust and respect.</div>
<div class="graf graf--p" name="cec4">
<br />
Look at the way you are managing your team right now for clues. Your team wants to learn things, and they should be making some of their own technical decisions. To make good decisions, they need to have context for their work (the customer feedback, product goals, and technical challenges). If you’re currently providing them with only a limited view of outstanding tickets or work to be implemented, you should broaden their access to context and give them a voice in the direction their work might take. If you haven’t yet, look to develop new leaders on your team. If you’re tempted to say they’re all “too junior” to be leaders it’s likely that you haven’t developed the coaching skills yet that you will need to manage another manager successfully.</div>
<div class="graf graf--p" name="43ff">
<br />
Look at the teams around you, and your relationships with those teams. Developing strong peer relationships is critical to leading an organization effectively. If you are regularly at odds with the managers or the tech leads of other teams, spend some time repairing those relationships. Ideally you can develop enough trust that they will come to you for advice. You might need to start by asking them for advice or doing favors for them without any expectation of immediate return. You want to be seen as a leader beyond your team, and that starts by acting as a collaborative partner.</div>
<div class="graf graf--p" name="07c8">
<strong class="markup--strong markup--p-strong"><br /></strong></div>
<div class="graf graf--p" name="07c8">
<strong class="markup--strong markup--p-strong">Does your manager want you reporting to her? </strong>The third question, beyond basic scaling and the ability to convince other managers that they might do well working for you, is the question of whether a more senior manager wants you reporting directly to her.</div>
<div class="graf graf--p" name="bed2">
<br />
This depends on you, your manager, and the options that your manager has available. If your manager has to decide between someone who needs a ton of coaching and someone who already knows how to do the job, it’s unlikely she’s going to choose the person who needs a lot of coaching to run the team. Especially if she is already stretched thin. In general, if you’re managing managers, your boss wants you to be able to operate independently. She wants someone capable of dealing with most people problems without escalating them, smoothing over conflicts within their team and with peer teams, and who can represent the team well to third parties within the company.</div>
<div class="graf graf--p" name="69bb">
<br />
That being said, if you lack the experience but have shown yourself to be open to feedback and coachable, you are much more likely to be chosen than a random outsider. Many people people get tripped up here without realizing it. So many line managers think that they are temporarily embarrassed CTOs, and don’t realize that they are lacking in many critical skills. If you bristle at every bit of corrective feedback, if you have an outsized ego that everyone can see, or even if you simply never actually act on the feedback that you get, you’re not going to be top of the list when the opportunities come about.<br />
<br /></div>
<h3>
<strong class="markup--strong markup--h4-strong">But how am I supposed to learn these skills if I don’t have a team to practice on!</strong></h3>
<div class="graf graf--p" name="5b7f">
Don’t despair. Just because you are only managing a single, smaller team doesn’t mean you can’t develop the skills and show that you can add more to the overall org. Here are some ideas for areas to focus on, in no particular order:</div>
<ol class="postList">
<li class="graf graf--li" name="66e3">Is your team a well-oiled machine, delivering clean code regularly and partnering well with other teams in the org? If not, perhaps you need to make sure your local house is in great working order, because it’s hard to get promoted if you aren’t seen as effective with your current scope.</li>
<li class="graf graf--li" name="a248">Look into how you can help your larger organization. This could be volunteering for organizational tasks such as: helping develop the interview process, running hackweek, organizing open source initiatives, etc. It could mean identifying processes within your organization that are less than ideal, and working to put in place concrete improvements. These will give you practice managing via influence, a valuable skill for most senior managers.</li>
<li class="graf graf--li" name="8476">How are your relationships with other managers and tech leads in your organization? Are you friendly and collaborative? Do you sometimes do things for their teams without expecting something in return? Building partner relationships with other teams nearby can help make you a possible candidate for leading those teams when there is an opening for a leadership change. But resist the urge to provide unsolicited advice to your peers! Your well-meaning advice will come across as a signal that you think you could do their job better, and that rarely goes over well.</li>
<li class="graf graf--li" name="641a">Are you presenting a professional face to the team? Are your working hours reliable? Do you respond to email in a reasonable timeframe? Are you thoughtful in your communication style? Do you come prepared to meetings or do you always look like you’re about to fall asleep at the table? In other words, is your boss going to worry that you’ll make her look bad? If so, work on that. Otherwise you’ll be fighting an uphill battle.</li>
</ol>
<div class="graf graf--p" name="1e57">
If all else fails, you can certainly try to jumpstart your career by moving to another part of your organization or another company entirely. But my advice, especially if you like the company you’re working for, is to start by making sure you’re not holding yourself back.<br />
<br /></div>
<div class="graf graf--p" name="2af3">
<em class="markup--em markup--p-em">Enjoy this post? You might like my book, </em><a class="markup--anchor markup--p-anchor" data-href="http://amzn.to/2nw1QN5" href="http://amzn.to/2nw1QN5" rel="nofollow noopener nofollow noopener noopener noopener" target="_blank"><em class="markup--em markup--p-em">The Manager’s Path</em></a><em class="markup--em markup--p-em">, available on Amazon and Safari Online!</em></div>
Camille Fournierhttp://www.blogger.com/profile/05090020862261633248noreply@blogger.com0tag:blogger.com,1999:blog-8221886912876606828.post-14236227869503027942018-09-22T09:18:00.000-07:002018-09-22T09:18:42.751-07:00Engineering Productivity<div class="graf graf--p" name="d3ec">
I’m often asked about the characteristics of great engineering managers. This is a question that almost always has a long answer that involves “well, she’s good at X, and he’s good at Y, and then there’s Z…” Every management role is slightly different, and a great engineering team will have managers who reflect a set of complimentary skill sets (such as operations, people management and coaching, product-focus) that are aligned with what their subgroup most needs.</div>
<div class="graf graf--p" name="d3ec">
<br /></div>
<div class="graf graf--p" name="21c5">
However, for most of us, there is one characteristic that is not optional or debatable, which is that a great engineering manager is capable of creating a highly productive engineering team. This is one of the distinguishing characteristics of the management side of engineering. Call it what you will — drive for results, goal-oriented — if you are not great at getting your team to be productive, this is a critical growth opportunity.</div>
<div class="graf graf--p" name="21c5">
<br /></div>
<div class="graf graf--p" name="7eae">
How do I know this is important? Ask any engineering manager at a startup what one of their most dreaded questions is, and they will almost certainly mention “why isn’t it done yet?” Engineering productivity is a hard thing to measure, but most of us know intuitively what it feels like to be on a productive team. We’re shipping things, we’re focused, we feel like we know what we’re doing and why it is important.</div>
<div class="graf graf--p" name="7eae">
<br /></div>
<div class="graf graf--p" name="f9f2">
So what are the management skills that are needed to achieve this result? At the first level of management, they look like:</div>
<ol class="postList">
<li class="graf graf--li" name="ddf1">Breaking down the scope of projects to help your team ship frequently. An eye for the MVP, for sequencing work and for predicting likely risks and bottlenecks for project completion are the skills here. This is why I think project management is such an important part of engineering leadership development, and why I hate to hand it off to professional project managers for work that doesn’t cross teams or organizations.</li>
<li class="graf graf--li" name="8905">Balancing that product delivery with sustaining engineering so that you don’t end up with code that can’t be maintained in the future. The amount you will invest here depends on the future certainty (baby startup? Probably not so much!), but there’s a reason we call it “technical debt” and that is because it inevitably comes due, unless you declare bankruptcy.</li>
<li class="graf graf--li" name="efae">Prioritizing, prioritizing, prioritizing. Implicit in the first two skills is the ability to figure out what is important, and prioritize it. If you overprioritize shipping, you might get a lot done for a while, and then slow down as the debt you’ve accumulated comes due. Overprioritize sustaining engineering and you don’t ship product. You may not start out with these instincts, but they can be developed, so don’t be afraid to start making judgment calls now and learning from the results.</li>
</ol>
<div class="graf graf--p" name="bfb7">
Managers who fail in these three areas quickly show why this is such an important skillset. Teams who don’t ship are usually disengaged and rarely get the positive feedback of seeing their work come to fruition. Teams who don’t ever clean up their tech debt end up burning out on the difficulty for supporting their software and the challenges building new features. And when teams don’t prioritize effectively, they end up burning cycles on things that are ultimately not that important which often contributes to a sense of purposelessness.</div>
<div class="graf graf--p" name="bfb7">
<br /></div>
<div class="graf graf--p" name="b031">
This is not the only thing that is important in engineering management, but without a focus on delivery, you are letting your team down in a critical way. So while you’re learning how to have good 1–1s, listen to people, create psychologically safe teams, and think about people’s careers, don’t forget that if your team isn’t shipping, you’re not doing your job. Nurturing a safe and healthy team helps your team do their best work, and helping them identify and deliver that best work is a key part of keeping them healthy.</div>
<div class="graf graf--p" name="b031">
<br /></div>
<div class="graf graf--p" name="9ea3">
<em class="markup--em markup--p-em">Enjoy this post? You might like my book, </em><a class="markup--anchor markup--p-anchor" data-href="http://amzn.to/2nw1QN5" href="http://amzn.to/2nw1QN5" rel="nofollow noopener noopener noopener" target="_blank"><em class="markup--em markup--p-em">The Manager’s Path</em></a><em class="markup--em markup--p-em">, available on Amazon and Safari Online!</em></div>
Camille Fournierhttp://www.blogger.com/profile/05090020862261633248noreply@blogger.com0tag:blogger.com,1999:blog-8221886912876606828.post-80167570403981193962018-07-29T10:00:00.000-07:002018-07-29T10:00:12.748-07:00Delegation: When being helpful is actually hurting<div class="graf graf--p" name="0305">
Effective delegation is one of the most critical skills a manager can learn. Without effective delegation, you fall victim to micromanaging your team, losing control of your time, and eventually failing to put yourself in a position where you can take on more and lead bigger things. There are many facets of effective delegation, and in this post I’m going to talk about one that tends to come from an otherwise good instinct: The failure to delegate because you are trying to be helpful.</div>
<figure class="graf graf--figure" name="9d8e"><img class="graf-image" data-height="558" data-image-id="0*ii4IKu3IaoFvjnzJ.jpg" data-width="992" height="225" src="https://cdn-images-1.medium.com/max/1600/0*ii4IKu3IaoFvjnzJ.jpg" width="400" /><figcaption class="imageCaption">Be Like Rep. Maxine Waters, and Reclaim Your Time!</figcaption></figure><h3 class="graf graf--h3 graf--startsWithDoubleQuote" name="53dc">
<br /></h3>
<h3 class="graf graf--h3 graf--startsWithDoubleQuote" name="53dc">
“How can I help?”</h3>
<div class="graf graf--p" name="2485">
I want my team to be happy and successful, and I want to feel useful and needed. So it’s not surprising that, when people bring me problems, my first instinct is to think of ways I can help them with these problems. Can I escalate it to one of my peers or my boss? Can I talk to the difficult employee for them, and try to improve the situation? Can I review the project plan and find the areas that are lacking detail and likely to cause the timeline to slip?</div>
<div class="graf graf--p" name="ed03">
As I’ve managed people with a lot of management experience themselves, I’ve noticed that they very rarely take me up on these offers. Instead, they tell me exactly how they are thinking about tackling the situation, perhaps listen to a few bits of advice from me, and then only ask for my direct intervention when their efforts have failed. It’s totally awesome! And it has taught me a lot indirectly about effectively managing my own time, and what good delegation looks like.</div>
<h3 class="graf graf--h3" name="9dac">
<br /></h3>
<h3 class="graf graf--h3" name="9dac">
Not My Monkeys, Not My Circus</h3>
<div class="graf graf--p" name="cc90">
So, what did their previous managers teach them that I need to learn how to do? Well, it turns out, their previous managers were probably pretty sensitive to something called “subordinate-imposed time.” I was introduced to this recently reading an old HBR article, “<a class="markup--anchor markup--p-anchor" data-href="https://hbr.org/1999/11/management-time-whos-got-the-monkey" href="https://hbr.org/1999/11/management-time-whos-got-the-monkey" rel="noopener" target="_blank">Management Time: Who’s Got the Monkey?”</a> Published originally in the 70s, this article took me a few read-throughs to really understand. Its focus is on controlling your time as a manager, and in particular, making sure you don’t take on too many tasks that are really the job of your subordinates.</div>
<div class="graf graf--p" name="4141">
The article uses a confusing-to-me analogy of monkeys riding on your back to describe these tasks. In simpler language, these are often the tasks that you take on when you are trying to be helpful to the people who work for you. Examples include:</div>
<ul class="postList">
<li class="graf graf--li" name="5c39">One of your directs asks for your input on a complex decision, and you take ownership of studying the factors and making that decision</li>
<li class="graf graf--li" name="f566">Telling someone on your team that you want to review a proposal before they send it out. </li>
<li class="graf graf--li" name="5c63">Volunteering to provide the first draft of goals for a project that a member of your team owns. </li>
</ul>
<div class="graf graf--p" name="f24b">
These are all examples of reasonable things that someone might ask for your help on (and all things I’m sure I have done!). However, the way you choose to provide that help is key. In each of the cases above, you’ve taken over a piece of work from someone that works for you. You’re making the decision, insisting on final review of the proposal, and starting the project work. </div>
<div class="graf graf--p" name="1df7">
How would you approach these situations if you were instead determined to leave the delegation on your team member, and make sure that you didn’t use a lot of your time doing their work? Well, you might:</div>
<ul class="postList">
<li class="graf graf--li" name="1c24">Talk over the decision in your 1–1, provide them with suggestions, but let them make the final call and justify it to the stakeholders</li>
<li class="graf graf--li" name="0c85">Review the doc in your 1–1 or another meeting specifically set up for this purpose (<em class="markup--em markup--li-em">if they requested your review or if this is something they’re still learning how to do</em>), but otherwise provide feedback at the same time that other stakeholders are given the doc</li>
<li class="graf graf--li" name="7b7f">Let them set up the first draft of the goals, and again in the context of your 1–1 or a review set up for this purpose, review the goals that they have drafted and provide your feedback</li>
</ul>
<div class="graf graf--p" name="f4ab">
You might object, all these meetings! But most of these touch bases can be done in the context of your weekly 1–1 (and in my experience doing this, most of them are). This frees you up outside of these scheduled, planned meeting times to focus on other important tasks that come from your own boss, the company and your peers, and things you want to get done for yourself. And most importantly, it puts the initiative squarely on the shoulders of your team, which is almost always where it belongs. They aren’t going to learn how to make good decisions, set good goals, or write effective docs, if you are always there providing a safety net or taking over the hard work from them. </div>
<h3 class="graf graf--h3" name="dc4d">
<br /></h3>
<h3 class="graf graf--h3" name="dc4d">
Reclaiming My Time</h3>
<div class="graf graf--p" name="9ecd">
So the next time you find yourself tempted to volunteer to take over responsibility for something from someone who reports to you, pause. Instead of taking it over, ask them what they think the next steps should be. Give your feedback, and let them bring the follow-ups to you in the next appropriate touch base. You owe it to them to stop taking over their work in the name of helpfulness.</div>
<div class="graf graf--p" name="f2ff">
<em class="markup--em markup--p-em"><br /></em></div>
<div class="graf graf--p" name="f2ff">
<em class="markup--em markup--p-em">For further reading, the classic HBR Article linked above, </em><a class="markup--anchor markup--p-anchor" data-href="https://hbr.org/1999/11/management-time-whos-got-the-monkey" href="https://hbr.org/1999/11/management-time-whos-got-the-monkey" rel="noopener" target="_blank"><em class="markup--em markup--p-em">“Management Time: Who’s Got the Monkey”</em></a><em class="markup--em markup--p-em"> has much more detail, including a very useful scoping of how much initiative someone is showing on a scale from “waiting to be told what to do” to “acting on their own, then routinely reporting.” And of course, you can always read my book, </em><a class="markup--anchor markup--p-anchor" data-href="http://amzn.to/2FvjeHH" href="http://amzn.to/2FvjeHH" rel="noopener" target="_blank"><em class="markup--em markup--p-em">The Manager’s Path</em></a><em class="markup--em markup--p-em">.</em></div>
Camille Fournierhttp://www.blogger.com/profile/05090020862261633248noreply@blogger.com0tag:blogger.com,1999:blog-8221886912876606828.post-13131830025411799212018-03-06T18:08:00.001-08:002018-03-06T18:08:28.501-08:00Are you out of alignment?<div class="graf graf--p" name="bc44">
Alignment, in the teamwork sense, means “a position of agreement or alliance.” It is one of the critical qualities that determines success in an organization, particularly at higher levels.</div>
<div class="graf graf--p" name="bc44">
<br /></div>
<div class="graf graf--p" name="6b69">
Many individual contributors (ICs) get stuck at a certain point in their career because they can’t see that they are out of alignment with their company, and they don’t realize that the way alignment is achieved has changed for them. In the earlier part of your career, you can be relatively well-aligned just by doing a pretty good job on the things you are asked to do. You get an assignment, presumably from someone who knows what is important to do, and you do it well. As you grow as an engineer, maybe the technical implementation details of those assignments get more challenging, the tasks get bigger, but as long as you keep conquering them, you are fine.</div>
<div class="graf graf--p" name="6b69">
<br /></div>
<div class="graf graf--p" name="ec6f">
That is until some point you realize that you’re still good at conquering the tasks, getting those hard problems solved, but you aren’t really getting promoted any more.</div>
<div class="graf graf--p" name="ec6f">
<br /></div>
<div class="graf graf--p" name="2f8c">
Sometimes this comes on slowly, and it looks like boredom. There are fewer and fewer of those meaty big technical problems for you to work on. You assume that they don’t need your skills. You get jealous that people aren’t asking for your advice before they build things, because clearly you know better!</div>
<div class="graf graf--p" name="2f8c">
<br /></div>
<div class="graf graf--p" name="ddc7">
Or it comes on all at once. You are told explicitly that you should find the next thing you want to work on, and you look around and don’t know what to look for. There’s no obvious problem that breaks down into what you know how to do. Or you find something, and you dig in. You get a prototype finished, and everyone yawns. Maybe it gets used for something small, but instead of changing the world for your team, people don’t seem all that impressed, and the things they are impressed by seem so trivial, boring, and technically easy by comparison!</div>
<div class="graf graf--p" name="ddc7">
<br /></div>
<div class="graf graf--p" name="74d6">
My friend, you have discovered that you are out of alignment.</div>
<div class="graf graf--p" name="74d6">
<br /></div>
<div class="graf graf--p" name="e9e3">
There are a lot of obvious ways people are misaligned to their companies. The classic “not a cultural fit” is one. If you fight against every process, decision, person around you, even if you’re right, that alignment mismatch will hurt you.</div>
<div class="graf graf--p" name="e9e3">
<br /></div>
<div class="graf graf--p" name="6ff9">
The more subtle way that most of us get out of alignment is by being unwilling to admit that we don’t understand what’s important to the company. We maybe don’t want to understand. We want to do things that are fun and challenging and interesting to us and have that work out to be the important thing. But for the fun things to be the important thing effortlessly is pretty rare. At a certain level, creating the alignment between projects that are interesting for you and what is needed by the company is a big part of your job.</div>
<div class="graf graf--p" name="6ff9">
<br /></div>
<div class="graf graf--p" name="bfbb">
Getting into alignment with the company is often a challenge for senior ICs because it requires a major change in focus. The hardest part is now identifying the <em class="markup--em markup--p-em">right</em> problem to solve, instead of solving the hardest problem. If you want to be able to find interesting work and also work on important things, you generally have to go find the interesting important things yourself. This requires that you to talk to a lot of people and listen to their problems, and then place a bet on a solution to one of these problems that will actually both be feasible but will also be seen as important. Your manager might help identify people that you could talk to, but you must take responsibility for doing the legwork and making the final choice in problems to address.</div>
<div class="graf graf--p" name="bfbb">
<br /></div>
<div class="graf graf--p" name="41fb">
The alternative way to resolve this alignment issue is to force yourself to address problems that you don’t want to solve, problems that are perhaps not as glamorous to you but are clearly important for the success of the company. Taking responsibility for cleaning up an area that feels intractably broken is not the job for every engineer, but for some people it is an easier and more obvious path to alignment and success. The risk you take here is that you either burn out fighting to fix a situation that is really about people and organizational issues that are beyond your scope, or you pick a broken area that no one really cares about fixing.</div>
<div class="graf graf--p" name="41fb">
<br /></div>
<div class="graf graf--p graf--hasDropCapModel graf--hasDropCap" name="e709">
<span class="graf-dropCap">In</span> both of these scenarios, you are taking more risk than you used to in the past, and that is where the second part of the quest for alignment comes in. It’s not just about being willing to find the work to do, it’s about finding the most important work that is right for you to do. The more attuned you are to the needs of the company, the kinds of work that is highly valued, the more likely you are to put your energy into something that will pay off well for you.</div>
<div class="graf graf--p graf--hasDropCapModel graf--hasDropCap" name="e709">
<br /></div>
<div class="graf graf--p" name="88df">
I often say that at more senior levels you get promoted for making wise bets, and really what that means is that you are smart enough to know the payout for what you’re pursing. Whether it’s knowing which fire to put out first, or having an idea for the thing to build to make your whole team more effective, the better-aligned you are to the needs and values of the organization, the more likely you are to be successful.</div>
<div class="graf graf--p" name="88df">
<br /></div>
<div class="graf graf--p" name="8b27">
<em class="markup--em markup--p-em">Enjoy this post? You might like my book, </em><a class="markup--anchor markup--p-anchor" data-href="http://amzn.to/2nw1QN5" href="http://amzn.to/2nw1QN5" rel="noopener" target="_blank"><em class="markup--em markup--p-em">The Manager’s Path</em></a><em class="markup--em markup--p-em">, available on Amazon and Safari Online!</em></div>
Camille Fournierhttp://www.blogger.com/profile/05090020862261633248noreply@blogger.com0tag:blogger.com,1999:blog-8221886912876606828.post-44250329368108471382018-01-13T08:28:00.000-08:002018-01-13T08:28:29.791-08:00Stop answering your own questions<div class="graf graf--p" name="fb24">
I have a bad habit. I noticed it today as I was leaving a comment in a strategy document. I’d highlighted some text that I found unclear and commented:</div>
<blockquote class="graf graf--blockquote graf--startsWithDoubleQuote" name="1a4d">
“Do you mean X or Y? Because I don’t think it is reasonable for us to do Y”</blockquote>
<div class="graf graf--p" name="9e1a">
This is one of my bad management habits. I jump to conclusions. I pretend to ask a question but then make it clear that only one answer can be right.</div>
<div class="graf graf--p" name="4452">
It is probably obvious why this is bad. While I do want to know more, in this framing, I am talking to hear myself speak, rather than genuinely asking for more information that would help me understand the plan and allow me to give better feedback. By stating my preference up-front I cut off discussion. What’s worse, I make the receiver unlikely to honestly answer my question; unless, that is, they feel up to the task of debating me.</div>
<div class="graf graf--p" name="4452">
<br /></div>
<h4 class="graf graf--h4" name="8ddc">
Get Curious</h4>
<div>
<br /></div>
<div class="graf graf--p" name="460c">
In writing you can review what you have said and edit your phrasing to eliminate this kind of thing, but it’s significantly more difficult when you’re in verbal conversation. When you’re talking you don’t have a chance to see yourself poisoning the well and cutting off opinions before they can be explained. This is one of the many reasons I have tried to embrace the mantra <em class="markup--em markup--p-em">get curious. </em>I use this phrase to remind myself that I have to make room for people, that my first reaction is not always the right one, and that when I hear something that doesn’t sound right I need to listen more rather than jump all over it.</div>
<div class="graf graf--p" name="9be8">
If you are (or were) a highly opinionated engineer, practicing making space for information rather than quickly jumping in and sharing your conclusions is a must for leadership growth. The more senior you become, the harder it is for people to feel comfortable disagreeing with you openly. That is not a sign of weakness on their part! Most people with any sense of self-preservation know that saying the wrong thing to the wrong person can have negative consequences. Lucky for you, as the manager, people are going to listen to what you have to say. Unlucky for you, as the manager, if you don’t make space for them to say things that you disagree with, you are unlikely to hear important details.</div>
<div class="graf graf--p" name="adc7">
Making good decisions requires you to get as much information as possible, to understand the nuances of the scenario from all angles. It is very difficult to do that if people are afraid to contradict you. One of the less-obvious ways we make people afraid is by offering our opinions too early, without taking the time to get the rest of the information. So the next time you’re tempted to ask a question and answer it yourself, stop. Get curious. You already know there’s something you don’t totally understand, so hold on stating your opinions until you’re sure you’ve gotten as much information as possible.</div>
<div class="graf graf--p" name="5c0b">
Now, to go edit that comment…</div>
Camille Fournierhttp://www.blogger.com/profile/05090020862261633248noreply@blogger.com0tag:blogger.com,1999:blog-8221886912876606828.post-36205392273316131552017-09-06T09:00:00.000-07:002017-09-06T09:00:27.343-07:00How do managers* get stuck?<div class="graf graf--p" name="4630">
<i>*May also apply to senior ICs</i></div>
<div class="graf graf--p" name="4630">
<br /></div>
<div class="graf graf--p" name="4630">
Earlier this year, I wrote a piece called <a class="markup--anchor markup--p-anchor" data-href="https://medium.com/@skamille/how-do-individual-contributors-get-stuck-63102ba43516" href="https://medium.com/@skamille/how-do-individual-contributors-get-stuck-63102ba43516" target="_blank">“How do Individual Contributors Get Stuck?”</a> This was an attempt to help ICs provide constructive feedback to their peers, by identifying common challenges that I have seen developers struggle to overcome. </div>
<div class="graf graf--p" name="875f">
<br /></div>
<div class="graf graf--p" name="875f">
This piece is a little bit different. I want to answer the question that I often hear from first-line managers, that is, managers who manage only individual contributors: “How do I get promoted to the next level of management? How do I prove I’m ready to manage managers?” </div>
<div class="graf graf--p" name="b267">
<br /></div>
<div class="graf graf--p" name="b267">
Managers often believe that if they are handling the demands of managing their team, they should naturally be promoted to manage more people, bigger teams, teams of teams, as quickly as such an opportunity comes about. And yet, just as often as those opportunities come about, someone else is chosen, a person is hired from outside the company, and the eager manager is passed over. You’re stuck. When you find yourself “stuck” in terms of management career progression, what might really be happening?</div>
<div class="graf graf--p" name="e1f4">
<br /></div>
<div class="graf graf--p" name="e1f4">
Usually, getting stuck as a manager falls into one or more of the key areas of management: Failing to manage down, failing to manage sideways, and failing to manage up.</div>
<h3 class="graf graf--h3" name="21d9">
<br /></h3>
<h3 class="graf graf--h3" name="21d9">
Scenario One: You aren’t actually scaling yourself effectively, aka, failing to manage down</h3>
<div class="graf graf--p" name="f29a">
You may think that you’re handling your team well, but when you look at your schedule, you’re working nights and weekends and then some to juggle all of the new tasks that managing a team entails. Sure, there are some companies which expect that from everyone, but it’s rarely a sign that you’re using your time effectively. Look at your team. Is it a well-oiled machine? Do you feel like the team is able to operate independently, get things done, without you micromanaging every detail? If not, you’re probably stuck on the basic needs of your current job. Some examples of this include:</div>
<ol class="postList">
<li class="graf graf--li" name="e0e6">Can’t delegate. Look at all hands-on tasks you own, and ask yourself whether you are the only person who could be completing these tasks, or whether you could assign them to another senior engineer. If you are spending a lot of your time doing hands-on work that someone else could be doing, you probably aren’t delegating effectively.</li>
<li class="graf graf--li" name="656b">Not training your team. If there are too many tasks that only you can complete, you have made yourself a key dependency for your team. Who are your potential successors, and have you spent time training them on the things only you can do?</li>
<li class="graf graf--li" name="cc06">Not enough attention to the process. Is your team drowning in alerts with no end in sight? Why haven’t you spent the time to allocate people to fix that? Have you spent time paying attention to the way work is assigned in your team? Do you actively participate in the planning process? When was the last time you tried changing it to see how it could improve? Process is part of your life now, and you need to tend to it.</li>
<li class="graf graf--li" name="5d62">Won’t say no. If your team is completely overwhelmed with work, well, it’s partially your fault. You are the manager, and you are the person who is responsible for pushing back on the work commitments for the team. </li>
</ol>
<h3 class="graf graf--h3" name="526c">
Scenario Two: You haven’t shown that you can expand beyond your team, aka, failing to manage up</h3>
<div class="graf graf--p" name="741c">
Maybe your team is running well enough, but that’s all you’re doing. Opportunities for advancement are usually given to people who show up for those opportunities. You can easily get stuck by just getting comfortable in the place that you’re sitting. Someone who is failing to manage up often exhibits one of the following problems:</div>
<ol class="postList">
<li class="graf graf--li" name="415e">Doesn’t attend to the details. Everything from clearly communicating the things that your team has accomplished, and sharing challenges or setbacks, to keeping your manager in the loop about major design decisions or roadmap changes, these details all matter. The best managers push information up without being asked and are quick to provide more details as necessary. Your manager wants to know that you are paying attention to what is going on.</li>
<li class="graf graf--li" name="2e02">Complains a lot about things that are not working well, but never volunteers to fix them. If you are free with your criticism about the way things work, but don’t feel the need to do anything more than complain, you are holding yourself back. Instead of complaining, volunteer to lead the initiative to fix that team-wide problem. Bring problems <strong class="markup--strong markup--li-strong">and </strong>solutions.</li>
<li class="graf graf--li" name="774f">Drags her feet when given a clear task that is outside of her comfort zone. I have seen so many managers fail at the simple act of taking a clear assignment and seeing it through to completion. When your manager asks you to do something, either do it, or say you can’t/don’t really want to. But don’t just drag your feet and fail to do it.</li>
<li class="graf graf--li" name="534a">Doesn’t show a professional face to more senior managers. Do you openly look bored, distracted, or impatient in meetings? Do you write emails that communicate clearly? Do you think your manager would be comfortable having you present to her peers, alone? Your verbal, written, and body language communication is more and more important the more senior you become, and if you are lazy here it can hold you back.</li>
</ol>
<h3 class="graf graf--h3" name="cf43">
Scenario Three: Fails to show peer leadership, aka, failing to manage sideways</h3>
<div class="graf graf--p" name="88d2">
Some people have well-running teams, they jump on fresh assignments, and yet they still get stuck. This is often due to the fact that your manager knows that she cannot put you as the manager to any of your existing peers. You are stuck because you haven’t shown enough peer/relationship management. This can sometimes look like:</div>
<ol class="postList">
<li class="graf graf--li" name="2618">Doesn’t build strong peer relationships. If you spend most of your time focused downward or upward, you’re missing a step. When was the last time you helped out one of your peers? How often do you spend time with your peers, 1–1? Do you seek out feedback from your peers on your ideas, or ask them for help with your challenges? Having peers who trust and respect you, and more to the point, who might want to work for you if they had to, is needed for successful growth.</li>
<li class="graf graf--li" name="f096">Doesn’t look for additional tasks. You should be looking for opportunities to lead projects or initiatives outside of your team. How can you help your peers? You may be the best person to lead your area, but if you rarely push yourself outside of that area to talk to others and see places you could volunteer to improve, you’re missing a critical element of leadership.</li>
<li class="graf graf--li" name="4993">Doesn’t create a compelling vision or strategy that others want to buy into. You might have a clear roadmap for your team, but how much have you thought beyond your team? Have you ever shared any ideas you have for the larger group with your peers, and gotten their buy-in? Many people think that strategic thinking starts and stops with forming the strategy itself, but getting people around you excited by your ideas is critical to achieving them. </li>
<li class="graf graf--li" name="7f59">Doesn’t seem like someone a manager would want to report to. Ultimately, if you want to manage managers, a manager should want to work for you. That means that you are going to help train them, help them grow their career. You’re <strong class="markup--strong markup--li-strong">not</strong> going to be spending all of your time telling them exactly what to do, when to do it, no questions asked. If one of your peer line managers wouldn’t want to work for you, you might be stuck on giving the impression that you’re looking to progress solely so that you can acquire more power and influence.</li>
</ol>
<h3 class="graf graf--h3" name="a619">
What about senior ICs?</h3>
<div class="graf graf--p" name="0aa0">
As you may have noticed, this advice applies to more than first-line managers. Many senior individual contributors start to trip on these issues. They can crank out code for days, but communicating, getting buy in, and going outside of their comfort zone stops their progression. Few senior ICs get promoted beyond a point on the strength of their ideas and code alone. </div>
<h3 class="graf graf--h3" name="f79f">
<br /></h3>
<h3 class="graf graf--h3" name="f79f">
Getting Unstuck</h3>
<div class="graf graf--p" name="9580">
How do you get out of your rut? It starts by noticing where you are stuck. I noticed something that I’m not doing well just writing this list! Be honest, which of these are you really doing well at, and which are you failing? If you brought this list to your manager, what would they say? There’s only one real way to find out, so think about it, ask for feedback, and start to formulate your plan of attack for the things that are holding you back.</div>
<div class="graf graf--p" name="5b3e">
<em class="markup--em markup--p-em">For more ideas, check out my book, </em><a class="markup--anchor markup--p-anchor" data-href="http://amzn.to/2wFw0iZ" href="http://amzn.to/2wFw0iZ" rel="noopener" target="_blank"><em class="markup--em markup--p-em">The Manager’s Path</em></a><em class="markup--em markup--p-em">, which addresses many of these stuck points!</em></div>
Camille Fournierhttp://www.blogger.com/profile/05090020862261633248noreply@blogger.com0tag:blogger.com,1999:blog-8221886912876606828.post-2992451464536852192017-01-06T07:50:00.000-08:002017-01-06T07:50:44.280-08:00How Do Individual Contributors Get Stuck? A Primer<div class="graf graf--p" name="0806">
Occasionally, you may be asked to give constructive feedback on your peers, perhaps as part of review season. If you aren’t a naturally critical person but you want to give someone a valuable insight, you may find this task daunting. To that end, I suggest the following:</div>
<div class="graf graf--p" name="0806">
<br /></div>
<div class="graf graf--p" name="5606">
<strong class="markup--strong markup--p-strong"><span style="font-size: large;">Pay attention to how they get stuck.</span></strong></div>
<div class="graf graf--p" name="9292">
<br /></div>
<div class="graf graf--p" name="9292">
Everyone has at least one area that they tend to get stuck on. An activity that serves as an attractive sidetrack. A task they will do anything to avoid. With a bit of observation, you can start to see the places that your colleagues get stuck. This is a super power for many reasons, but at a baseline, it is great for when you need to write a review and want to provide useful constructive feedback.</div>
<div class="graf graf--p" name="ea52">
How do people get sidetracked? How do people get stuck? Well, my friend, here are two incomplete lists to get you started:</div>
<div class="graf graf--p" name="ea52">
<br /></div>
<h3 class="graf graf--h3" name="7953">
Individual Contributors often get sidetracked by…</h3>
<ol class="postList">
<li class="graf graf--li" name="f19f">Brainstorming/architecture: “I must have thought through all edge cases of all parts of everything before I can begin this project”</li>
<li class="graf graf--li" name="bee5">Researching possible solutions forever (often accompanied by desire to do a “bakeoff” where they build prototypes in different platforms/languages/etc)</li>
<li class="graf graf--li" name="f42a">Refactoring: “this code could be cleaner and everything would be just so much easier if we cleaned this up… and this up… and…”</li>
<li class="graf graf--li" name="88db">Helping other people instead of doing their assigned tasks</li>
<li class="graf graf--li" name="031c">Jumping on fires even when not on-call</li>
<li class="graf graf--li" name="36c6">Working on side projects instead of the main project</li>
<li class="graf graf--li" name="4385">Excessive testing (rare)</li>
<li class="graf graf--li" name="7e85">Excessive automation (rare)</li>
</ol>
<h3 class="graf graf--h3" name="d2dc">
Individual Contributors often get stuck when they need to…</h3>
<ol class="postList">
<li class="graf graf--li" name="643c">Finish the last 10–20% of a project</li>
<li class="graf graf--li" name="5c33">Start a project completely from scratch</li>
<li class="graf graf--li" name="c135">Do project planning (<em class="markup--em markup--li-em">You need me to write what now? A roadmap?</em>)</li>
<li class="graf graf--li" name="d66d">Work with unfamiliar code/libraries/systems</li>
<li class="graf graf--li" name="7f86">Work with other teams (<em class="markup--em markup--li-em">please don’t make me go sit with data engineering!!</em>)</li>
<li class="graf graf--li" name="43d5">Talk to other people (in engineering, or more commonly, outside of engineering)</li>
<li class="graf graf--li" name="c233">Ask for help (far beyond the point they realized they were stuck and needed help)</li>
<li class="graf graf--li" name="e815">Deal with surprises or unexpected setbacks</li>
<li class="graf graf--li" name="58e0">Navigate bureaucracy</li>
<li class="graf graf--li" name="f2b0">Pull the trigger and going into prod</li>
<li class="graf graf--li" name="9186">Deal with vendors/external partners</li>
<li class="graf graf--li" name="e5c5">Say no, because they can’t seem to just say no (instead of saying no they just go into avoidance mode, or worse, always say yes)</li>
</ol>
<div class="graf graf--p graf--startsWithDoubleQuote" name="f884">
<em class="markup--em markup--p-em">“AHA! Wait! Camille is missing something! People don’t always get stuck!” </em>This is true. While almost everyone has some areas that they get overly hung up on, some people also get sloppy instead of getting stuck. Sloppy looks like never getting sidetracked from the main project but never finishing anything completely, letting the finishing touches of the last project drop as you rush heedlessly into the next project.</div>
<div class="graf graf--p graf--startsWithDoubleQuote" name="f884">
<br /></div>
<div class="graf graf--p" name="72bb">
Noticing how people get stuck is a super power, and one that many great tech leads (and yes, managers) rely on to get big things done. When you know how people get stuck, you can plan your projects to rely on people for their strengths and provide them help or even completely side-step their weaknesses. You know who is good to ask for which kinds of help, and who hates that particular challenge just as much as you do.</div>
<div class="graf graf--p" name="72bb">
<br /></div>
<div class="graf graf--p" name="f46d">
The secret is that <strong class="markup--strong markup--p-strong">all of us get stuck and sidetracked sometimes</strong>. There’s actually nothing particularly “bad” about this. Knowing the ways that you get hung up is good because you can choose to either a) get over the fears that are sticking you (lack of knowledge, skills, or confidence), b) avoid such tasks as much as possible, and/or c) be aware of your habits and use extra diligence when faced with tackling these areas.</div>
Camille Fournierhttp://www.blogger.com/profile/05090020862261633248noreply@blogger.com0tag:blogger.com,1999:blog-8221886912876606828.post-15829294729072456262017-01-04T19:31:00.000-08:002017-01-04T19:31:08.790-08:00Hey Diddle Diddle, Data to FiddleWhen I worked in finance ages ago, there was a system used by many (but not me!) that was basically a combination of a gigantic distributed database plus a scripting language that allowed you to run calculations over information in that database. One of the things that you could easily do, as far as I understand, was "diddle" a piece of information. The "diddle" would change that piece of data inside of a particular scope, so that you could quickly see different calculations over the graph, without necessarily persisting that data back to the larger system. This was a useful construct for exploring what might happen with changes to different input data and exploring different scenarios. (The <a href="http://blog.podsnap.com/reactive.html">first half of this blog post</a> provides some insights into how the system might have worked).<br />
<br />
Whether my understanding is exactly right or not is irrelevant except that this concept of "diddling" stuck with me. There are times when what you want to do is take persistent data, make a small change to it on the fly, and use the results of that change without necessarily persisting it back to the original data set.<br />
<br />
I've often thought that this concept is particularly useful in places like personalization. Imagine the situation where you have a complex set of results that you wish to display to a user, like say, the google search results. We all know that the ranking system for google results is a complex beast, relying on a huge amount of precomputed data, for example, the links between pages. But now, to compute that graph with personalization taken into account? You're probably not calculating all personalization vectors on the fly, but when I go to search for "java" you're also probably not doing a lookup of pre-computed personalized results for "java + userid:camille." Instead, you're applying a "diddle" function to the top set of the overall graph, and showing me the results in the diddled order that makes sense for me.<br />
<br />
There are two parts to the concept that make it powerful for me. The first is the idea that you are changing things temporarily. To serve large sets of results fast (or, in the case of google, to be able to function at all), you need to pre-calculate a huge amount of data. You're doing a complex piece of work that takes some time, you don't want to have to redo it for every request. However, you don't want to force yourself to store all the work for all possible scenarios up-front. But, diddling in my mind presents a second element: it is only applied to the set of data within a limited scope. You don't diddle across the entire search index. You diddle the first few results, the ones that matter to the user in question.<br />
<br />
There can be a ton of technical complexity to implement such a concept in practice. One immediate challenge is that of "diddling" in such a way as to drop results from the top set, thus requiring a re-querying for additional responses to get enough data to satisfy the user. The purpose of this post is not to go into the technical details of how you might implement such a thing, but to show you that you can reframe your thinking on a problem like this through its phases. Just because you have a list of thousands as your first pass of results doesn't mean you need to personalize across that whole data set to get the best results for the end user. If your goal is to get the most personally relevant of the most generally relevant, you probably want to operate on the top of the generally-ordered list, not necessarily the whole list itself.<br />
<br />
There's many ways to attack such problems, and I have no idea how companies like Google solve the challenge of personalizing results under the hood. I do know that, to me, the idea of mixing indexed and computed results in personalized querying is a sticky one, and it's an analogy I use frequently. It helps you remember that there is value in the underlying order of the results as provided by the source of truth, and that personalization is often an enhancement on an underlying set of computed data, not the fundamental computation itself. Pulling out to a larger picture, remember that when your data gets in front of a human end-user, they are going to operate on only the tiny surface area they, as a human, can process at any one time. So in cases where you're serving humans, you can apply different patterns on the fly to the human-visible surface area that would be too expensive to apply to the entire data set at large.Camille Fournierhttp://www.blogger.com/profile/05090020862261633248noreply@blogger.com0tag:blogger.com,1999:blog-8221886912876606828.post-13818106103504160032016-11-29T07:18:00.000-08:002016-11-29T07:18:04.437-08:00Building and Motivating Engineering TeamsI have agreed to give a guest lecture for <a class="markup--anchor markup--p-anchor" data-href="https://mgt656.som.yale.edu/" href="https://mgt656.som.yale.edu/" target="_blank">a class at Yale</a>, and they’ve asked me to speak about “building and motivating engineering teams” from the perspective of a smaller startup. The readings for my section include <a class="markup--anchor markup--p-anchor" data-href="http://www.joelonsoftware.com/articles/FieldGuidetoDevelopers.html" href="http://www.joelonsoftware.com/articles/FieldGuidetoDevelopers.html" target="_blank">A Field Guide to Software Developers</a> by Joel Spolsky. I remember reading it when it was first written. I admire Joel’s work, and the piece has many valuable takeaways.<br />
<br />
<div>
<br /></div>
However. The industry has changed a lot in the years since this piece was written. In 2007, the options for engineers here in NYC were far more limited. You worked for a bank, a media company, ad tech was starting to blossom, some e-commerce. Google or Fog Creek if you were lucky. There were plenty of jobs but there was far less of a classic “tech company” presence than there is today. <br /><br />Over the past 9 years, we’ve seen a massive increase in the number of startups here in NYC. Every major tech company has an office here, the Google office alone has thousands of engineers. We’ve also seen an increase in the supply of engineers. Between students realizing the value of a tech degree, people changing careers, and bootcamps rapidly churning out graduates, the mix of types of people who write software has changed. Most of the people I knew writing software in 2007 had tech or tech-adjacent (math, physics) degrees. My team when I left Rent the Runway had a significant number of developers who had moved into tech from other areas, some without degrees at all. <br /><br />All of this is to say, playing to 2007 nerd stereotypes is not always a good way to build a team here in NYC. What DO engineers want? I believe that you have 3 axes with which to twiddle. Depending on your company, you can lean more on one to cover problems with the others, but you have to find your balance. <br /><br /><b>Money</b>. Joel hides this at the bottom of his piece. It is correct to say that engineers don’t care about money above all else, but far too many people delude themselves into thinking that this means that you can lag industry standard salaries and build a good team on the basis of some other factor. <br /><br />Salaries have gone way up in the past 10 years. People know that they can get paid a certain amount of money, and if you try to hire people who can easily make 50% more somewhere else, they are almost certainly not going to accept your offer. Figure out what the market spread is. The top will be companies like Google, Facebook, some financial companies. The bottom might be non-profits or extremely early startups with significant equity grants. Even a startup with 10–20 people is going to struggle to hire without paying close to market rate. Engineers are expensive. New engineers are expensive. Senior engineers are really expensive. They know their value. You have to pay them. <br /><br />You are building a company. You are not going to have a perfect, smooth ride. Things will go well, things will go poorly. Very few teams have a straight shot to greatness that is so clear it can cover all management woes. When you don’t pay people well enough, you contribute to undermining their resilience in the face of problems at work. Think of it as the baseline of Maslow’s Hierarchy. Money does not solve all problems for most people, but lack of money exacerbates all irritations. <br /><br /><b> Purpose</b>. You’re building a company. You want to inspire people to work for you, so you sell them on the mission of the company, the product they’ll be working on. You have to do this because you are not building a company with a bunch of insanely hard tech problems. If you are, you can lean on that to hire people, but to be real, these days most of us are not. The days when everyone had hard technical scaling problems have ended. Scaling is not the same bold new frontier that it was even 5 years ago. Sure, there are always technical challenges to be found in organizations, but for many companies those technical challenges revolve around matching technology with the product and business. This means you have to work harder to sell the learning opportunities.<br /><br />Leadership undermines their teams when they refuse to let engineers into the non-technical decision-making processes. In Joel’s article he talks about developers wanting to be allowed to make decisions within their own realm of expertise, which is certainly a bare minimum. I would encourage you to go further than that. If you are building a product-focused business, where the challenges are less purely technical and more about engaging a customer, your engineers need to feel connection to that business. They need to feel like they understand it, like they can have ideas about it. This is why I’m such an advocate for cross-functional product development teams. Put engineering, product management, marketing, operations together as a group and let them work as a team to solve problems. Don’t just throw work over the wall to engineering and expect them to implement it.<br /><br /><b> Respect</b>. The undercurrent that I like least in Joel’s piece is the undercurrent that engineers need to be coddled and pampered. Giving them “toys” instead of “tools,” keeping them out of the politics. There are plenty of engineers who want to be given hard work to do and left alone, in their private offices, to think and code. But there are increasingly more engineers who want to build businesses, and they want to be treated like adults in the process.<br /><br />Our engineering teams are not overgrown children. They are not idiot-savants who can produce software but must be given sufficient cookies to do so. They are highly paid professionals. Let’s treat them that way. You should expect your engineers to show up for your business. Respect is not pampering, it is not treating the team like the stars of the show. Rather, respect is challenging the team to show up and grow up. Respect is giving them clear, achievable goals and holding them accountable. My experience has been that most great engineers want to work somewhere that inspires them to achieve. Many of us stop at the idea of “hard technical problem” when we think about inspiring our engineering teams, but challenging them to partner with people who have different perspectives is another way you can help them grow.<br /><br />Respect that engineers are smart individuals who often have more to add to your business than just their coding talents, and teach them to respect that the other parts of the business have equally valuable skills and perspectives. Engineers don’t need to feel like the company royalty to be inspired to do good work, but they do need the opportunity to be treated like a partner. <br /><br /><br />These days, you have a lot of competition for talent, but you also have a lot of talent to choose from. Understand your company’s positioning. If you can’t pay top of market, you will have to rely on a balance of finding undeveloped talent and giving engineers other reasons to want to work for your company. For most of us, that means giving them a voice beyond the purely technical, and challenging them to see and understand perspectives outside of engineering.<br />
<div>
<br /></div>
<div>
<a href="https://medium.com/@skamille/building-and-motivating-engineering-teams-24fd56910039#.1kgrom8om">Originally posted on Medium</a></div>
Camille Fournierhttp://www.blogger.com/profile/05090020862261633248noreply@blogger.com0tag:blogger.com,1999:blog-8221886912876606828.post-39354028039160175742016-08-19T06:44:00.001-07:002016-08-19T06:44:30.522-07:00Microservices: Real Architectural Patterns<h3 class="graf--h3" name="b47b">
A dissection of our favorite folk architecture</h3>
<h3 class="graf--h3" name="531f">
<br /></h3>
<h3 class="graf--h3" name="531f">
Introduction</h3>
<div class="graf--p" name="4f51">
<br /></div>
<div class="graf--p" name="4f51">
I’m fascinated by the lore and mystery behind <em class="markup--em markup--p-em">microservices. </em>As a concept, microservices feels like one of the most interesting folk architectures of the modern era. It’s useful enough to be applied widely across different usage patterns and also vague enough to mean many different things.</div>
<div class="graf--p" name="4f51">
<br /></div>
<div class="graf--p" name="599f">
I’ve been struggling for a while with understanding what people really mean when they discuss “microservices.” Despite deploying what I would consider to be a version of that pattern in my last gig, it’s quite clear to me that the architecture we used is not the same as the pattern that all other companies use. Recently I finally interrogated someone who has deployed the pattern in a very different way than I have, and so I decided it would be illustrative to compare and contrast the circumstances of our architectures for those in the larger technical audience.</div>
<div class="graf--p" name="599f">
<br /></div>
<div class="graf--p" name="4519">
This article is going to have two examples. The first is the rough way “microservices” was deployed in my last gig, and why I made the decisions I made in the architecture. The second is an example of an architecture that is much closer to the “beautiful dream” microservices as I have heard it preached, for architectures that are stream-focused.</div>
<h4 class="graf--h4" name="2da7">
<br /></h4>
<h4 class="graf--h4" name="2da7">
Microservices Basics</h4>
<div class="graf--p" name="bfaa">
<br /></div>
<div class="graf--p" name="bfaa">
I think that microservices as an architecture evolved due to a few factors.</div>
<ol class="postList">
<li class="graf--li" name="f3d1">A bunch of startups in the late 2000s started on monoliths like rails, scaled their business and team quickly, and hit the wall on what could reasonably be done in that monolith</li>
<li class="graf--li" name="5f61">The cloud made it significantly easier to get access to a new server instance to run software</li>
<li class="graf--li" name="5c47">We all got much more comfortable with the idea that we were dealing with distributed systems and in particular got comfortable making network calls as part of our systems</li>
</ol>
<div class="graf--p" name="15a2">
This combination of factors — scaling woes, easy access to new hardware, distributed systems and network access — played a huge part in what I might call “microservices for CRUD.” If you have managed to scale a company to a certain level of success on a monolith but you are having trouble scaling the technology and/or the engineering team, breaking the monolith into a services-style architecture makes sense. This is a situation I encountered first-hand.</div>
<div class="graf--p" name="15a2">
<br /></div>
<div class="graf--p" name="de7a">
The arguments for microservices here look something like:</div>
<ol class="postList">
<li class="graf--li" name="1669">Services allow for independent axes of scaling. If you have a part of the system with higher load or capacity requirements than other parts, you can scale to meet its needs. This is certainly doable in a monolith, but somewhat more complicated to reason about.</li>
<li class="graf--li" name="d255">Services allow for independent failure domains, to a more limited extent. Insofar as parts of your system are independently operable, you may want to allow for partial availability by splitting them out into services. For example, in a commerce app, if you can serve the checkout flow even when the product search flow is down, that might be considered a good thing. This is much more complicated in practice than it is in theory, and people make many silly claims about microservices that imply that any overlap in services means that they are not valuable. Independent failure domains are sometimes more of a “nice to have” than a necessity, and making the architecture truly account for this is not easy.</li>
<li class="graf--li" name="8a11">Services allow for teams to work independently on parts of the system. Again, you can do this in a monolith. I have done this in a monolith. But the challenge with monolith (and a related challenge with services in a monorepo (single source repository)) is that humans struggle to tangibly understand domains that are theoretically separate when they are presented as colocated by the source code. If I can see all of the code and it all compiles together and feels like a single thing, my tendency is to want to use it as a single thing. Grab code from here to use there, grab data from there to use here, etc.</li>
</ol>
<div class="graf--p" name="f06f">
A few more notes. “Monolith” and “monorepo” often get tangled up when talking about this world. A monolithic application is one where you have a set of code that compiles into a single main server artifact (possibly with some additional client artifacts produced). You can use configuration to make monoliths do almost anything you can imagine, including all of the services-type things above, but the image produced tends to include most if not all of the code in the repository. This does get fuzzy because sometimes teams evolve their monoliths to compile to a couple of specialized server artifacts via a combination of build tooling and configuration. I would generally still call this a monolithic architecture.</div>
<div class="graf--p" name="f06f">
<br /></div>
<div class="graf--p" name="b910">
Monorepo, or monolith repository, is the model where you have a single repository that holds all of the code for any system you are actively changing (so, possibly excluding the source code for your OSS/external dependencies). The repository itself contains source code that accounts for multiple artifacts that are run as separate applications, and which can be compiled/packaged and tested separately without using the entire repository. Often this is used to enable certain shared libraries to change across all of the services that use those libraries, so that developers who support shared libraries can more easily evolve them instead of having to wait for each dependent team to adopt the newest version. The biggest downside of the monorepo model is that there’s not much OSS tooling that supports this, because most OSS is not built this way, so large investments in tooling are usually needed to make this work.</div>
<h4 class="graf--h4" name="c727">
<br /></h4>
<h4 class="graf--h4" name="c727">
Microservices for CRUD-based Applications</h4>
<div class="graf--p" name="7eda">
<br /></div>
<div class="graf--p" name="7eda">
Before I get to how to evolve a CRUD monolith to microservices, let me further articulate the architecture needed to build your traditional mid-sized CRUD platform. This type of platform covers a use case that is pretty well-trod, that of “transactions” and “metadata.”</div>
<div class="graf--p" name="7eda">
<br /></div>
<blockquote class="tr_bq">
Transactions: User does an action that you want to persist, consistency of data is very valuable. The “Create, Update, Delete” of CRUD. Much less frequent than the “Read” actions of CRUD. </blockquote>
<blockquote class="tr_bq">
Metadata: Information that describes things to the users, but is usually only modified by internal content creators, or rarely by external users (reviews, for example). Changes less frequently, often highly cacheable. Even more, can often tolerate a degree of temporary inconsistency (showing stale data).</blockquote>
<div class="graf--p" name="0592">
Are there more things that CRUD-heavy companies want to do, especially in the analytical space here? Sure. You may want to adjust results frequently based on user behavior as the user is browsing the site, and other personalization actions. However, that is a hard thing to do real-time and you don’t always have the volume of data you need from the user to actually do that well, so it isn’t generally the first-order concern of the system.</div>
<div class="graf--p" name="0592">
<br /></div>
<div class="graf--p" name="f685">
The process for moving off of a monolith in this type of architecture is relatively straightforward:</div>
<ol class="postList">
<li class="graf--li" name="8c1c">Identify independent entities. This paper by Pat Helland, <a class="markup--anchor markup--li-anchor" data-href="http://adrianmarriott.net/logosroot/papers/LifeBeyondTxns.pdf" href="http://adrianmarriott.net/logosroot/papers/LifeBeyondTxns.pdf">“Life Beyond Txns”</a>, has some useful and interesting definitions there. It’s better to go a little bit too big early than to go too small and end up having to implement significant distributed transactions. You probably want data-owning services for the major business objects(products, users, etc), and then sets of integration services that implement aggregations and logic over those objects.</li>
<li class="graf--li" name="2734">Pull out the logic into services entity by entity. Try not to change the data model as much as possible in this process. Redirect the monolith to call APIs in the new services as functionality is moved.</li>
</ol>
<div class="graf--p" name="8d53">
That’s basically it. You pull pieces out until you have enough to cover a particular set of user functionality in data and integration terms, then you can start to evolve that part of the user functionality to do new things in the services.</div>
<div class="graf--p" name="8d53">
<br /></div>
<div class="graf--p" name="6591">
These services are not classic SOA, but nor are they teeny-tiny microservices. The services that own the data may be fairly sophisticated. You may not want to have too many services because you want to be able to satisfy requests from the user without having to make a ton of network hops, and ideally, without needing to do distributed transactions.</div>
<div class="graf--p" name="6591">
<br /></div>
<div class="graf--p" name="92de">
You are probably not making new services every day, and especially if you have a sub-50-person engineering team and a long product roadmap, you may not want to invest extensive engineering time into complex orchestration and tooling that enables people to dynamically add new services at the click of a button <em class="markup--em markup--p-em">(nb: the products to support this are getting better all the time, and so at some point this will be worth doing even for that smaller team. It is unclear to me whether that time is now or not.)</em>.</div>
<div class="graf--p" name="92de">
<br /></div>
<div class="graf--p" name="42a3">
The equation to apply for determining how much to invest in tooling is pretty straightforward: how much time does it cost devs to have a less automated process for adding a new service, vs how long does it take to implement and maintain the automation for doing it easily, and how many new services do you expect to want to deploy over time? You’re making a guess. Obviously, if you think there is value to enabling people to spin up tiny services fast and frequently, it is better to invest time and tooling into this. As with all engineering process optimization decisions, it’s not a matter of getting it perfectly right, but rather, of deciding for the foreseeable future and periodically re-evaluating.</div>
<div class="graf--p" name="42a3">
<br /></div>
<div class="graf--p" name="28ae">
There are many microservices “must-haves” in this instance that I have found to be anything but. I mentioned extensive orchestration above. Dynamic service discovery is also not needed if you are not automatically spinning up services or moving services around frequently (load balancers are pretty nice for doing this at a basic level).</div>
<div class="graf--p" name="28ae">
<br /></div>
<div class="graf--p" name="e542">
Allowing teams to choose their ideal language, framework, and data store per service is also certainly not a must-have and in fact it’s likely to be far more of a headache than a boon to your team.</div>
<div class="graf--p" name="cdf4">
Having independent data stores for the services is also not a must-have, although it does mean that you will have a high-risk SPOF on the shared database. As I was writing this piece I discovered a section of<a class="markup--anchor markup--p-anchor" data-href="https://dzone.com/articles/adopting-microservices-netflix" href="https://dzone.com/articles/adopting-microservices-netflix"> some writing on microservices from 2015:</a></div>
<blockquote class="graf--blockquote" name="df6a">
Create a Separate Data Store for Each Microservice</blockquote>
<blockquote class="graf--blockquote" name="4c8f">
Do not use the the same back-end data store across microservices. … Moreover, with a single data store it’s too easy for microservices written by different teams to share database structures, perhaps in the name of reducing duplication of work. You end up with the situation where if one team updates a database structure, other services that also use that structure have to be changed too.</blockquote>
<div class="graf--p" name="af29">
This is true, but for smaller teams you can prevent sharing of database structures by convention (process and code review, and automated testing and checking for such access if it is a huge worry). When you carefully define the data-owner services, it’s less likely this will happen. And the alternative is the next paragraph:</div>
<blockquote class="graf--blockquote" name="f1d8">
Breaking apart the data can make data management more complicated, because the separate storage systems can more easily get out sync or become inconsistent, and foreign keys can change unexpectedly. You need to add a tool that performs <a class="markup--anchor markup--blockquote-anchor" data-href="http://en.wikipedia.org/wiki/Master_data_management" href="http://en.wikipedia.org/wiki/Master_data_management">master data management</a> (MDM) by operating in the background to find and fix inconsistencies. For example, it might examine every database that stores subscriber IDs, to verify that the same IDs exist in all of them (there aren’t missing or extra IDs in any one database). You can write your own tool or buy one. Many commercial relational database management systems (RDBMSs) do these kinds of checks, but they usually impose too many requirements for coupling, and so don’t scale.(<a class="markup--anchor markup--blockquote-anchor" data-href="https://dzone.com/articles/adopting-microservices-netflix" href="https://dzone.com/articles/adopting-microservices-netflix">original</a>)</blockquote>
<div class="graf--p" name="dcac">
This paragraph probably leads to sighs of exhaustion from anyone with experience doing data reconciliation. It’s due to this overhead that I encourage those of you in smaller organizations to at least evaluate a convention-based approach before deciding to use entirely independent and individual data stores. This is a decision you can delay as needed.</div>
<div class="graf--p" name="dcac">
<br /></div>
<div class="graf--p graf--hasDropCapModel graf--hasDropCap" name="549f">
<span class="graf-dropCap">T</span>his version of the microservices architecture is very compelling for the scaled CRUD world because it lets you do a rewrite piece by piece. You can do the whole system, or you can simply take out pieces that are most sensitive to scaling. You proactively engage with many of the bits of distributed systems complexity by thinking carefully about the data and where transactions on that data will be needed. You probably don’t need a ton of fancy data pipelines floating around. You know where the data will be modified.</div>
<div class="graf--p graf--hasDropCapModel graf--hasDropCap" name="549f">
<br /></div>
<div class="graf--p" name="b747">
Do you <em class="markup--em markup--p-em">have</em> to go to microservices to scale this? Probably not, but that doesn’t mean using microservices to scale such systems is a bad idea. However, going extreme with the microservices model <em class="markup--em markup--p-em">may </em>be a bad idea, because you really don’t want to slice your data up in a way that ends up in distributed transaction land.</div>
<h4 class="graf--h4" name="bc6f">
<br /></h4>
<h4 class="graf--h4" name="bc6f">
Microservices For Data Stream Processing</h4>
<div class="graf--p" name="d66e">
<br /></div>
<div class="graf--p" name="d66e">
Now, let’s talk about a very different use case. This use case is not your classic CRUD application, thick with business rules around transactionally-updated objects. Instead, this use case has a large pipeline of data. It has small bits of data flowing into it from many different sources, a very large volume of many bits of data. This large volume of input data sources also has many different services that will consume it, modify it, and pass it along for further processing.</div>
<div class="graf--p" name="d66e">
<br /></div>
<div class="graf--p" name="163e">
The major concern of this application is ingesting large quantities of ever-changing data, processing it in various ways, and showing a view of it to customers. CRUD concerns are secondary to the larger concerns of keeping up with the data stream and recalculating information based on what is happening on that stream.</div>
<div class="graf--p" name="163e">
<br /></div>
<div class="graf--p" name="21b5">
Let’s take a metrics-aggregating SaaS application, for example. This application has customers all over the world with various applications, services, and machines that are reporting out metrics to the aggregator. These customers only need to see their data, although the combined total of data for any one customer may be very large. Our aggregator needs to consume these metrics and send them off to the application that is going to show them to the customer. The customer-facing application may be operating on a combination of incoming metrics in real-time plus historical data that comes from cache or a backing storage system. A large part of the value of the data is in the moving-window of what is happening right now/recently.</div>
<div class="graf--p" name="21b5">
<br /></div>
<div class="graf--p" name="26be">
This architecture from the start has considerations of volume that even our scaled CRUD world may not care about for a very, very long time. Additionally, the data itself is mostly a stream of updates over time. The notion of the “stateful” data that is transactionally updated is minimal, the most useful data is more like a timeseries or log of events. The transactional data, say, stored user views and user configuration, may be more like the “metadata” of our CRUD application in the first example, infrequently changed compared to the updates coming in from the stream. The majority of developer time is most likely spent not in dealing with these transactional changes but rather in managing the streams of inputs, providing new types of inputs, applying new calculations to the stream of inputs, and changing the calculations.</div>
<div class="graf--p" name="26be">
<br /></div>
<div class="graf--p" name="38b0">
In this example, you can imagine a service that wants to run an experiment by doing a different calculation across a particular element on the stream. Instead of modifying the existing code, the experimental service listens to the data stream at the same point as the existing calculation, provides a new calculation value, and pushes that calculation value back into the data pipeline on a different channel. At some point an experiment service pulls this data out for the customers who are assigned to the experimental treatment and shows the results of that calculation instead of the standard calculation. In all of these places you need a record of what happened in order to do analysis of experiment success and debugging, but that record does not need to be strongly, transactionally related to the record of other events in the system at this time, even across related users.</div>
<div class="graf--p" name="38b0">
<br /></div>
<div class="graf--p" name="bb79">
In this example, it may very well be much more effective to spin up new services as needed, in order to run quick experiments, rather than changing existing services. Especially in cases where the service can do this without needing to worry about coordinating the data consumption or production with any existing service. This is the world of what I would like to call “stream-centric microservices.”</div>
<div class="graf--p" name="bb79">
<br /></div>
<div class="graf--p" name="6ec3">
If there is enormous value to your business to manage real-time data streams, and you are going to have a lot of developers consuming those streams by creating new services to listen to them and produce results, then you absolutely must be willing to commit to the investment in tooling to make the process of creating services and putting them into production as easy as possible. You will probably use this for all of your services over time, once you have it, but realize that the clear value is that you have dynamic data that can be processed and manipulated and experimented on independently.</div>
<h4 class="graf--h4" name="d172">
<br /></h4>
<h4 class="graf--h4" name="d172">
Cron Jobs as Microservices</h4>
<div class="graf--p" name="1f08">
<br /></div>
<div class="graf--p" name="1f08">
I’d be remiss if I didn’t mention this pattern. When it becomes very easy to make anything a microservice, everything becomes a microservice, including things we would traditionally run as cron jobs.</div>
<div class="graf--p" name="1f08">
<br /></div>
<div class="graf--p" name="a397">
But cron jobs are a nice concept, and not everything has to be a “service.” You can use CloudWatch Events from AWS for this purpose, or scheduled Lambda functions. Use Gearman, a queue and async job runner, to schedule cron jobs. Remember your cron jobs need to be idempotent (can be run twice on the same input without changing the outcome). If you have an easy way to spin up services and it’s easy to create tiny services that are basically cron jobs, no problem, but cron jobs in and of themselves are not a great reason to create a large, orchestrated services environment.</div>
<h3 class="graf--h3" name="95e1">
<br /></h3>
<h3 class="graf--h3" name="95e1">
Conclusion</h3>
<div class="graf--p" name="8aea">
<br /></div>
<div class="graf--p" name="8aea">
I hope that this has been a useful breakout across a few axes of the wild world of microservices. Going through the thought experiment was very useful for me, personally. It helped me understand how what seems obvious to people at one extreme, say those who spend most of their time focused on stream processing, doesn’t make as much sense for people who are more focused on the world of CRUD application scaling.</div>
<div class="graf--p" name="8aea">
<br /></div>
<div class="graf--p" name="8aea">
(This was originally published on <a href="https://medium.com/@skamille/microservices-real-architectural-patterns-68bd83bbb6cd#.dl7jrbr5k">medium</a>)</div>
Camille Fournierhttp://www.blogger.com/profile/05090020862261633248noreply@blogger.com0tag:blogger.com,1999:blog-8221886912876606828.post-5803755023293923522016-07-18T11:30:00.000-07:002016-07-18T11:30:07.325-07:00The Virtue of Hubris and The Value of Complaining<a href="http://www.elidedbranches.com/2016/06/the-virtues-of-laziness-and-impatience.html">In my previous post, I discussed the leadership virtues of Laziness and Impatience</a>. But as you may know, I neglected one of the core virtues in my list, namely, that of hubris. Hubris. Pride. As Larry Wall says,<br />
<blockquote class="tr_bq">
Excessive pride, the sort of thing Zeus zaps you for. Also the quality that makes you write (and maintain) programs that other people won't want to say bad things about. <a href="http://c2.com/cgi/wiki?LazinessImpatienceHubris">Hence, the third great virtue of a programmer.</a></blockquote>
I would translate this as taking pride in one's work, and being willing to not just take pride in it, but show off that work, talk about it, teach others its magic. And hubris is important. One of the challenges of impatience is that it sometimes drives us to cut corners. Cutting corners can make work go faster, but it can also have a price in the long run. So we balance that desire to cut corners with a desire to maintain pride in our work, and use those conflicting values to keep each other in check.<br />
<br />
Hubris done well in my opinion has some interesting expressions. You may think of the person who takes pride in their work as someone who loves to learn and share new things. Who loves to brag about the good stuff. This is certainly part of hubris, sharing lessons learned and trying to help others by showing off our wins. Many tech teams encourage this actively, through rituals like "drinks and demos" where teams get up to share what they accomplished during the week. We encourage people to write up cool stuff we've built, to go speak at conferences and talk about cool technology, and this is all a great thing to do.<br />
<br />
However, I think there's more to it than just showing off the good stuff. Within a team, hubris also shows in people who are willing to complain about the bad stuff. Yes, that's right, I think that there is value to expressing not just the positive, but also the negative. In fact, I think that you are actively harming your culture and creating a culture of false pride when you only encourage people to speak up to share good things.<br />
<br />
Complaining is all about context. The problems we are facing are our context, and the solutions to those problems must be made within understanding of that context. Context is what makes microservices right for one team and wrong for another. Context is what makes hiring a certain way successful in a high-growth startup but devastating in a big company. Context is so important that when you misunderstand the role that it plays in a solution, you run the risk of misapplying that solution to a place where it will cause you more problems than it solves. Applying someone else's lessons to your context without understanding is how we end up with these cargo cult solutions.<br />
<br />
So, the details of the problem are pretty important for putting the solution we're bragging about into context. But here's the thing. If you squash people who want to complain or criticize, you lose the details of your problems. Those complaints contain the details!<br />
<br />
Does your company have a practice of telling people to "bring solutions, not complaints?" That is at best hiding problems, not avoiding them. It is unrealistic to expect people to be able to solve every problem they see in front of them. I mean, can you do that, really? It is hard enough to expect your executives to be able to do this, believe me, I know. Your team is going to see problems that they will not know how to solve, and to tell them to keep that to themselves until they figure out the solution is a great way to avoid dealing with real issues.<br />
<br />
Instead, I encourage you to ask people to give you details when they have complaints. Help them put their complaints in context. If they complain a system sucks, ask them why. Maybe the answer is that they don't like the formatting standards, in which case an appropriate response might be, unfortunately not everything goes your way. On the other hand, maybe the answer is that it takes them a long time to make changes because the system has no tests and breaks easily, in which case, perhaps you want to think about actually fixing that problem.<br />
<br />
If you do this well, you actually teach people how to understand which problems are important, and which problems are not. Letting people complain might seem like it will do nothing but encourage negativity and drama, but if you guide people to learn from their complaints it can instead help your team grow. It's great when people can bring problems AND solutions to you simultaneously, but it's more likely that they will need help to see the best solution. Helping them see the best solution starts by helping them understand how to state the problem.<br />
<br />
We are going to have disagreements and conflict in our teams. None of us sees the world in the same way, and that is good. We form teams because as a group, sharing our perspectives, we can create things that are greater than the sum of their parts. Trying to create conflict-free environments is a fool's errand. But you can guide conflict and complaints to result in an increased understanding of context. Instead of discouraging all disagreement, push people to be specific about their thoughts and concerns, and attempt to understand them. As a leader, ask questions to tease out details, and show that you are actually interested in the perspectives on your team, even when you might disagree.<br />
<br />
Taking pride sometimes means speaking up when something doesn't seem to be right, when something seems to be less than what it could be. Criticism can help us become even better than we are, if we are willing to listen to its details. Please don't smother this in the name of harmony or positivity, because repressing conflict only leads to a false sense of security and prevents us from achieving true greatness.Camille Fournierhttp://www.blogger.com/profile/05090020862261633248noreply@blogger.com0tag:blogger.com,1999:blog-8221886912876606828.post-74036501027374028372016-06-10T09:08:00.000-07:002016-06-12T15:24:45.027-07:00The Virtues of Laziness and Impatience<i>This is an excerpt from my work in progress, a book on engineering management. If you're interested in getting occasional updates you can <a href="https://tinyletter.com/skamille">subscribe to my newsletter</a>!</i><br />
<br />
I love the idea of <b>Laziness, Impatience, and Hubris</b> as virtues of engineers, articulated in “Programming Perl” by Larry Wall. I believe these virtues sustain into leadership, and learning how to channel these traits into advantages is something I encourage all managers to do.<br />
<br />
As a manager, when you are dealing with people 1-1 you probably don’t want to be impatient, of course. Impatience can be rude when it is directed at individuals. And you don’t want to seem lazy, there’s nothing worse than working for a manager who seems to be taking it easy while you kill yourself to deliver projects. But impatience, paired with laziness, is wonderful when directed at processes and decisions. Impatience and laziness, applied to process, are the key elements to focus.<br />
<br />
As you grow more into leadership positions, people will look to you for behavioral guidance. What you want to teach them is how to focus. To that end, there are two areas I encourage you to practice showing, right now: figuring out what’s important, and going home.<br />
<br />
I can’t stand watching people waste their energy approaching problems with brute force and spending time rather than thought, and yet, any culture where you are encouraged to work excessive hours all the time is almost certainly doing just that. What is the value of automation if you don’t use it to make your job easier? We engineers automate so that we can focus on the fun stuff, and the fun stuff is the stuff that uses the most of your brain, and it’s not usually something you can do for hours and hours, day after day.<br />
<br />
So be impatient to figure out the nut of what is important. As a leader, any time you see something being done that feels inefficient, start to ask the question, why does this feel inefficient to me? What is the value in the thing we are doing? Can we deliver that value in a way that is faster? Can we strip down this project into something simpler and get it done more quickly?<br />
<br />
The problem with this line of questioning is that often when managers ask, can it be done faster, what they explicitly or implicitly want to know is, can the team work harder or longer hours to deliver it in fewer days. This is why I encourage you to develop and show the value of laziness. Because “faster” is not about “same number of hours but fewer total days.” “Faster” is about “the same value to the company in less total time.” If the team works 60 hours in a week to deliver something that otherwise would’ve taken a week and a half, they haven’t worked faster, they’ve just given the company more of their free time.<br />
<br />
This is where going home comes in. Go home! And stop emailing people at all hours of the night and all hours of the weekend! Forcing yourself to disengage is essential for your mental health, believe me. Burnout is a real problem in the American workforce these days, and almost everyone I know who has worked sustained excess hours has experienced it to some degree. It’s terrible for individuals, terrible for their families, and terrible for teams. But this isn’t just about preventing your own burnout, it’s about preventing your team’s burnout. When you work later than everyone else, when you send those emails at all hours, even if you don’t expect your team to respond to those emails or work those hours, they see you doing it, and think it’s important. And that overwork makes them less effective, especially at the detailed knowledge work that engineers need to perform.<br />
<br />
When you are a newish manager, and you haven’t figured out the tricks to do your job effectively, you might find yourself needing to work more hours to get it all done. That is ok, for a little while. But I encourage you to figure out a way to work those hours without encouraging your team to do so, or making them feel obligated to be on your schedule. Queue up the weekend and overnight emails for the next work day. Put your chat status as “away” in off hours. Take vacation and don’t answer email during that time. And constantly ask yourself the same questions you ask your team: can I do this faster? Do I need to be doing this at all? What is the value that I am providing with this work?<br />
<br />
<h4>
Laziness and impatience. We focus so we can go home, and we encourage going home because it forces us to constantly focus. This is how great teams scale.</h4>
Camille Fournierhttp://www.blogger.com/profile/05090020862261633248noreply@blogger.com3tag:blogger.com,1999:blog-8221886912876606828.post-46061632053454095152016-05-05T11:59:00.001-07:002016-05-05T12:12:13.531-07:00Thoughts on Take Home InterviewsThere is a movement now in tech to really think about what it would take to improve our interview process. This is a movement a long time coming. White board coding interviews are clearly a strange way to measure a person's ability to actually do the day to day work of a modern software engineer. And we know that we tend to have a lot of bias in our interview processes that takes what we wish were an objective evaluation of skills and turns it into something very, very subjective.<br />
<br />
<a href="https://slack.engineering/a-walkthrough-guide-to-finding-an-engineering-job-at-slack-dc07dd7b0144#.6ilsr1bv6">Recently, my friend Julia Grace wrote about the interview process at Slack</a>, to grant more transparency into what it takes to become an engineer at one of the hottest companies around. While this is a recruiting tactic it's also great that they are helping people understand what to expect and how to apply. Slack is taking pains to try to avoid bias, by having people complete a take-home technical exercise.<br />
<blockquote class="tr_bq">
<blockquote class="tr_bq">
This varies by position, but generally you’ll have a week to complete a technical exercise and submit the code and working solution back to us.</blockquote>
<blockquote class="tr_bq">
Since we don’t do any whiteboard coding during the onsite interview, the technical exercise is one of the best ways we’ve found to evaluate programming competency.</blockquote>
<blockquote class="tr_bq">
The exercise is graded against a rigorous set of over 30 predetermined criteria. We’re looking for code that is clean, readable, performant, and maintainable. We put significant effort into developing these criteria to ensure that, regardless of who grades the exercise, the score is an accurate reflection of the quality of the work. We do this to limit bias. If there are clear criteria, variations that might impact score but have nothing to do with the candidate (such as if the grader is having a good day) are less likely to influence the outcome.</blockquote>
</blockquote>
On twitter, a discussion ensued about whether asking people to spend time at home doing exercises didn't itself cause bias, against those who did not have a lot of spare time to be doing take-home exercises. Julia mentioned that they expect it to take 2-4 hours, but admitted that some people got really into the project and spent far longer than that.<br />
<br />
This brings up three good questions that I want to address:<br />
<h3>
1) Are take-home exercises on the balance good?<br />2) Is it reasonable to expect people to spend 2-4 hours of their own time on a take-home exercise?<br />3) What about the people who will spend more time?</h3>
<br />
On the issue of 1, I think that yes, take-home exercises can help a lot to address the bias that happens when you know the person who wrote the code. They have the potential to be the blind audition step that the tech industry needs.<br />
<br />
On the issue of 2, I actually ALSO think it is ok to ask candidates to spend a few hours on these exercises. This comes with two caveats. First, you should genuinely believe that the exercise can be done in the number of hours you expect by a candidate qualified for that level (so, measure how long candidates report spending on it). Second, these exercises only take "a few hours," not "tens of hours."<br />
<br />
I feel ok, within bounds, to say that you should find a few hours to do a coding assignment, especially if it reduces the time you would need to spend onsite. The benefits of getting rid of whiteboard coding and that particular bit of evaluation bias outweigh the possible inconvenience. If you're looking for a job, you have to budget time to interview. So take half a day off if you can to do this project. Just because the exercise says take home doesn't mean you actually have to do it in your off hours. If you're unable to take time off of work to interview at all, unfortunately, you're going to have a problem getting a new job anywhere.<br />
<br />
Which brings us to issue 3, what about the people who will spend more time? This is the most interesting part.<br />
<br />
Julia said that candidates get really into solving the problem, and spend more time on it because they're excited about what they're building. That is awesome, but it also makes my blood run cold. At this point you're talking about something that is both a test of your programming abilities but also a creative project. Let's contrast that to the <a href="http://engineering.foursquare.com/2016/04/04/improving-our-engineering-interview-process/">description that Foursquare gives of their take-home portion:</a><br />
<br />
<blockquote class="tr_bq">
<blockquote class="tr_bq">
Instead we give out a take-home exercise that takes about three hours. The exercise consists of three questions:</blockquote>
<blockquote class="tr_bq">
1. A single-function coding question</blockquote>
<blockquote class="tr_bq">
2. A slightly more complicated coding question that involves creating a data structure</blockquote>
<blockquote class="tr_bq">
3. A short design doc (less than a page) on how to implement a specific service and its endpoints.</blockquote>
<blockquote class="tr_bq">
Every question we use is based on a real problem we’ve had to solve and has a preamble explaining the reason we need to solve this problem. If there is an obvious solution with a poor running time we mention it since we can’t help course-correct when the work isn’t being done live. We also provide scaffolding for the coding questions to save the candidate time.</blockquote>
</blockquote>
This appears to be designed as an exercise that will only require a lot more time if you are struggling with the solution. Sure you can go nuts creating a crazy creative data structure or design doc, but this is a pretty clinical test. There's few places to add bells and whistles and they're unlikely to get you any brownie points with the interviewers.<br />
<br />
These are two processes with the same goal, to reduce bias in our interviewing process, but slightly different tactics in the take-home. I would guess that Slack's take-home is fun and appealing to a set of people, those who enjoy tinkering or creating cool new projects. And it will find those people and make them shine, and probably serve as a good bit of recruiting to make them even more excited about the possibility of working there.<br />
<br />
But I can tell you that for someone like me, I would hate being given the "creative" take-home coding problem. I'm happy to write some code to show you that I can. But I don't like to tinker, and I prefer that my creative work be collaborative. It feels like you are wasting my time and instead of making me more excited, it makes me far less excited.<br />
<br />
The creative take-home also seems likely to select for those with free time, because if it is really an exercise that some people want to overdo, they will overdo it and you will have a hard time not rewarding that enthusiasm (why shouldn't you!). And while it's ok to ask for a few hours, building something that rewards those who can spend far longer is likely to bias against those who have, say, kids to take care of after work and on weekends, or other activities that limit their free time.<br />
<br />
On the other hand, Foursquare's test is the first take-home I ever read about where I thought, "yes, that I would do." It is respectful of my time, and gives me something constrained to complete. We can elaborate on creative topics in the in-person interview, I do much of my best creative thinking with other people, elaborating on ideas together. Of course, I am a strong in-person communicator, and having a process that pushes the creativity into the in-person interaction interviews selects for people like me.<br />
<br />
In the end, you probably want to hire a spectrum of people. When thinking about how to design your take-home tests, make sure that you are being considerate of the candidate's time, and decide if you really need this test to be a test of both technical skills and creativity, or merely a screening for technical skills. It may be that different roles need different screenings, and you may even want to offer both! That's a lot to ask for, but no one ever said that fixing hiring was going to be easy.<br />
<br />Camille Fournierhttp://www.blogger.com/profile/05090020862261633248noreply@blogger.com6