text:
tag:blogger.com,1999:blog-82218869128766068282020-05-09T13:10:12.758-07:00Elided BranchesCamille Fournierhttp://email@example.com: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.

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.

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.

What's so hard about product for (internal) platform?

Customer Group Size
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.

Captive Audience
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.

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.

It's Hard To Think Like Your Customer
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.

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.

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.

So how do you solve this?
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:

Assimilate and Expand
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?

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.

Partner to Prototype
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.

Make a Migration Strategy Early
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.

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.

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.

You Aren't Google, So Don't Build When You Don't Have To
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."

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.

Summing Up
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.

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.

Thanks to my darling product and platform friends for their feedback on drafts, especially Renee and Pete.

Enjoy this post? You might like my book, The Manager's Path, available on Amazon and Safari Online!Camille Fournierhttp://email@example.com: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)
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?

The setup

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.

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.

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.

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.

Escaping the Trap

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.

So how do you decide where to exert your energy?

Step one: Figure out who owns this problem

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!

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?

If it's someone else's job, how much does it affect your day to day life? Does it bother you because they're doing it wrong, 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!

Step two: Talk to all the people

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.

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!

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.

Step three: Plan the fix

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!

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.

Step four: Enact the plan

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?

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.

Step five: Think about how many of these you can actually do

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.

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.

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?

Pick Your Culture First and Foremost

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.

Flowchart courtesy twitter user https://twitter.com/felidelg

Enjoy this post? You might like my book, The Manager's Path, available on Amazon and Safari Online!
Camille Fournierhttp://firstname.lastname@example.com:blogger.com,1999:blog-8221886912876606828.post-88371110635116287052018-11-23T07:49:00.001-08:002018-11-23T07:49:44.076-08:00I hate manager READMEs

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:

Dropping f-bombs is one of my "quirks"

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 this article on the concept. 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.

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

Look, fellow managers: there is no way 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.

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.

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).

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.

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 some feedback, sometimes, but not this feedback, not at this time, not in this way.

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.

One of the worst parts of these docs is the airing of your own perceived personality faults. I suck at niceties. I get heated sometimes in discussions. I don't give praise very much. If you know you have foibles/quirks that you in fact want to change about yourself, do the work. 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.

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

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.

I've gotten a LOT of coaching

You know where these kinds of docs are 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.

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:

You're probably just wasting your time, because no one reads the docs anyway!

If you'd rather read something funny, check out Tim's parody, "A User Guide from My 5-year-old"

Enjoy this post (or hate it)? You (still) might like my book, The Manager's Path, available on Amazon and Safari Online!

Camille Fournierhttp://email@example.com: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?
When I wrote "The Manager's Path" 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?

First, look at the role you are currently playing. 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.

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.

How to go from line manager to managing managers

The promotion path forward generally depends on a few things.

Can you scale your team effectively? 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!

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.

Would other managers want to work for you? 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.

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.

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.

Does your manager want you reporting to her? 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.

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.

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.

But how am I supposed to learn these skills if I don't have a team to practice on!

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:

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.

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.

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.

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.

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.

Enjoy this post? You might like my book, The Manager's Path, available on Amazon and Safari Online!
Camille Fournierhttp://firstname.lastname@example.com:blogger.com,1999:blog-8221886912876606828.post-14236227869503027942018-09-22T09:18:00.000-07:002018-09-22T09:18:42.751-07:00Engineering Productivity
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.

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.

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.

So what are the management skills that are needed to achieve this result? At the first level of management, they look like:

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.

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.

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.

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.

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.

Enjoy this post? You might like my book, The Manager's Path, available on Amazon and Safari Online!
Camille Fournierhttp://email@example.com: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
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.

Be Like Rep. Maxine Waters, and Reclaim Your Time!

"How can I help?"

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?

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.

Not My Monkeys, Not My Circus

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, "Management Time: Who's Got the Monkey?" 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.

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:

One of your directs asks for your input on a complex decision, and you take ownership of studying the factors and making that decision

Telling someone on your team that you want to review a proposal before they send it out.

Volunteering to provide the first draft of goals for a project that a member of your team owns.

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.

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:

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

Review the doc in your 1–1 or another meeting specifically set up for this purpose (if they requested your review or if this is something they're still learning how to do), but otherwise provide feedback at the same time that other stakeholders are given the doc

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

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.

Reclaiming My Time

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.

For further reading, the classic HBR Article linked above, "Management Time: Who's Got the Monkey" 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, The Manager's Path.
Camille Fournierhttp://email@example.com: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?
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.

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.

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.

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!

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!

My friend, you have discovered that you are out of alignment.

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.

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.

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 right 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.

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.

In 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.

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.

Enjoy this post? You might like my book, The Manager's Path, available on Amazon and Safari Online!
Camille Fournierhttp://email@example.com: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
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:

"Do you mean X or Y? Because I don't think it is reasonable for us to do Y"

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.

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.

Get Curious

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 get curious. 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.

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.

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.

Now, to go edit that comment…
Camille Fournierhttp://firstname.lastname@example.com: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?
*May also apply to senior ICs

Earlier this year, I wrote a piece called "How do Individual Contributors Get Stuck?" 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.

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?"

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?

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.

Scenario One: You aren't actually scaling yourself effectively, aka, failing to manage down

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:

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.

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?

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.

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.

Scenario Two: You haven't shown that you can expand beyond your team, aka, failing to manage up

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:

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.

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 and solutions.

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.

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.

Scenario Three: Fails to show peer leadership, aka, failing to manage sideways

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:

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.

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.

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.

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 not 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.

What about senior ICs?

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.

Getting Unstuck

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.

For more ideas, check out my book, The Manager's Path, which addresses many of these stuck points!
Camille Fournierhttp://firstname.lastname@example.com: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
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:

Pay attention to how they get stuck.

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.

How do people get sidetracked? How do people get stuck? Well, my friend, here are two incomplete lists to get you started:

Individual Contributors often get sidetracked by…

Brainstorming/architecture: "I must have thought through all edge cases of all parts of everything before I can begin this project"

Researching possible solutions forever (often accompanied by desire to do a "bakeoff" where they build prototypes in different platforms/languages/etc)

Refactoring: "this code could be cleaner and everything would be just so much easier if we cleaned this up… and this up… and…"

Helping other people instead of doing their assigned tasks

Jumping on fires even when not on-call

Working on side projects instead of the main project

Excessive testing (rare)

Excessive automation (rare)

Individual Contributors often get stuck when they need to…

Finish the last 10–20% of a project

Start a project completely from scratch

Do project planning (You need me to write what now? A roadmap?)

Work with unfamiliar code/libraries/systems

Work with other teams (please don't make me go sit with data engineering!!)

Talk to other people (in engineering, or more commonly, outside of engineering)

Ask for help (far beyond the point they realized they were stuck and needed help)

Deal with surprises or unexpected setbacks

Navigate bureaucracy

Pull the trigger and going into prod

Deal with vendors/external partners

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)

"AHA! Wait! Camille is missing something! People don't always get stuck!" 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.

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.

The secret is that all of us get stuck and sidetracked sometimes. 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.
Camille Fournierhttp://firstname.lastname@example.com: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 first half of this blog post provides some insights into how the system might have worked).

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.

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.

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.

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.

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://email@example.com: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 at Yale, 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 Field Guide to Software Developers by Joel Spolsky. I remember reading it when it was first written. I admire Joel's work, and the piece has many valuable takeaways.

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.

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.

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.

Money. 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.

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.

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.

 Purpose. 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.

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.

 Respect. 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.

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.

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.

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.

Originally posted on Medium
Camille Fournierhttp://firstname.lastname@example.com:blogger.com,1999:blog-8221886912876606828.post-39354028039160175742016-08-19T06:44:00.001-07:002016-08-19T06:44:30.522-07:00Microservices: Real Architectural Patterns
A dissection of our favorite folk architecture

Introduction

I'm fascinated by the lore and mystery behind microservices. 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.

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.

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.

Microservices Basics

I think that microservices as an architecture evolved due to a few factors.

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

The cloud made it significantly easier to get access to a new server instance to run software

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

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.

The arguments for microservices here look something like:

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.

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.

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.

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.

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.

Microservices for CRUD-based Applications

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."

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.

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).

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.

The process for moving off of a monolith in this type of architecture is relatively straightforward:

Identify independent entities. This paper by Pat Helland, "Life Beyond Txns", 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.

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.

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.

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.

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 (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.).

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.

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).

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.

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 some writing on microservices from 2015:

Create a Separate Data Store for Each Microservice

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.

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:

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 master data management (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.(original)

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.

This 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.

Do you have 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 may 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.

Microservices For Data Stream Processing

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.

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.

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.

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.

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.

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."

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.

Cron Jobs as Microservices

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.

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.

Conclusion

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.

(This was originally published on medium)
Camille Fournierhttp://email@example.com: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 ComplainingIn my previous post, I discussed the leadership virtues of Laziness and Impatience. 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,

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. Hence, the third great virtue of a programmer.
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.

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.

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.

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.

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!

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.

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.

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.

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.

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://firstname.lastname@example.com: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 ImpatienceThis is an excerpt from my work in progress, a book on engineering management. If you're interested in getting occasional updates you can subscribe to my newsletter!

I love the idea of Laziness, Impatience, and Hubris 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.

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.

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.

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.

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?

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.

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.

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?

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.
Camille Fournierhttp://firstname.lastname@example.com: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.

Recently, my friend Julia Grace wrote about the interview process at Slack, 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.

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.

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.

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.

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.

This brings up three good questions that I want to address:

1) Are take-home exercises on the balance good?
2) Is it reasonable to expect people to spend 2-4 hours of their own time on a take-home exercise?
3) What about the people who will spend more time?

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.

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."

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.

Which brings us to issue 3, what about the people who will spend more time? This is the most interesting part.

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 description that Foursquare gives of their take-home portion:

Instead we give out a take-home exercise that takes about three hours. The exercise consists of three questions:

1. A single-function coding question

2. A slightly more complicated coding question that involves creating a data structure

3. A short design doc (less than a page) on how to implement a specific service and its endpoints.

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.

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.

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.

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.

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.

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.

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.

Camille Fournierhttp://email@example.com:blogger.com,1999:blog-8221886912876606828.post-39652525819687060702016-04-28T10:18:00.001-07:002016-04-28T10:18:27.539-07:00Ask the CTO: Getting Information without interruptionsThis is reposted from my Ask the CTO series on O'Reilly

The problem: I don't know how to figure out what's happening on my teams without asking people directly, and it's driving them crazy!

I am in charge of a team that is running a big, critical project. My boss is breathing down my neck at all times, asking me for status updates, wondering when different pieces are going to be done. Usually, I know what is happening because I'm doing some of the work myself, so I can give the answers because I'm deeply involved in the project. This time, however, I'm not actually doing any of the work, and I don't even have the time to attend every planning meeting and standup. When my boss asks me for status updates, I feel that I have no choice but to ask a member of the team.

Of course, there's also the outages. Did I mention that this big project is to replace a system that is crumbling and causing incidents all the time? So, if I'm not asking about project status, I'm trying to figure out why we're down, what the status of the incident is, if there's anything I can help with.

I just got some feedback from the tech lead: I'm driving the team crazy with my one-off questions. They complain that I'm distracting them, interrupting their work, and derailing other important discussions to get status updates. I don't want to do that, but I don't know how to figure out what's going on without tapping someone on the shoulder to ask. What do I do?

The solution: Know where to look

When you are embedded in the team you are leading, the details of their projects are the air you breathe. But add on more teams or a level of management and all of those details provide hard to discover. How do you get the status of projects when you are a step or two removed? How do you figure out what is going on without constantly tapping an engineer on the shoulder and asking her for a status update?

To begin with, you have to know where to look. If it is important that you know the status for projects at the drop of a hat, then you should learn how to read the project management dashboards the team is using. If the teams are not using task tracking and project management software, at this point I must ask, why not? It is one thing to avoid the overhead of formal task tracking in a very small group. However, as the team grows, you need to have transparency into progress. This means that you need a sense of what the tasks that make up "progress" look like, which requires some sort of breakdown and tracking, even if it is in the form of sticky notes on the wall.

This also goes for your production incidents. What is your incident management process? Are incidents managed via chatroom, or by people sitting in the office together? Do you have a postmortem process? If ongoing incidents don't have a communication process and structure, it might be time to throw something together.

Knowing where to look is the first element, one that managers often skip over too quickly. You owe it to your team to look at the existing tracking software and look for the status there first, before firing off questions directly to the engineers. However, looking through the project tickets and work-in-flight status does not always provide the full picture. Sometimes the person managing the project tracking is themselves a bit disorganized. Sometimes the details that you are concerned with are not represented, or not represented well. Then what do you do?

Practical advice: Manage up, read the room, and let the team lead

Let's break down this situation further, because "then what" really depends on the time and the urgency, and the reasons behind your question.

Scenario 1: You're asking because your boss asked about the project and you didn't have a great answer.

That's fine! But does your boss need more details this second? Or can you ask the team for details in the context of scheduled meetings or via less-urgent communication channels (email or chat)? Usually when the boss asks us something, that makes us want to jump quickly. What we really need to do is just make a note to get more information and then get it when the time is right. This requires some managing up. Predict the questions that your boss tends to ask, and have some general answers prepared. That will give you some ammunition to use as you push back for time to get details on specific concerns. And you will need to push back occasionally. The worst outcome is having your boss go directly to the team themselves and ask for a status update.

Open office plans provide the most tempting setup for interrupting people. Picture: you have a question you're itching to get an answer for, the manager of the team is in a meeting that you can't interrupt, but there's one of the engineers sitting there typing away. The temptation to tap him on the shoulder and ask can be overwhelming. I know it is for me. If you're going to do this, for goodness sakes, respect the signals. Is this person wearing headphones and look really focused? Or is he chatting, walking around, or otherwise out of the zone? Be sensitive about your impatience versus their focus, and apologize when you are forced to interrupt their work. Apologies don't cure all evils, but making an effort here is important.

Scenario 2: You're asking because launch of this work is imminent, or this work relates to an immediate production issue and you need nuanced details that only a developer can provide.

In this case, you may very well need to interrupt someone and reading the room will be essential. There are times when managers, for whatever reason, are themselves either occupied with something else or don't understand the nuance of the situation you are concerned with, e.g., a release is at-risk and you don't know why. Sometimes, asking the developers for details will tease out decisions that could change a release from "late" to "on-time minus a non-essential feature." The goal is to do this very sparingly, and use it as a teaching opportunity instead of a chance to undermine.

In the book Turn the Ship Around (an essential leadership text for engineering teams that I've recommended several times already), the authors spend a lot of time discussing how to resist taking the wheel every time a small problem happens and thus undermining the leadership and ownership of the members of the team. The way you choose to ask for details in the moment can make the difference between encouraging leadership from the team and enabling learned helplessness that causes the team to be paralyzed without you around. Instead of barking orders in a production outage or telling people to cut features close to a launch, practice using these situations to ask them what they intend to do. Asking what they intend to do puts the ball in their court, and forces them to practice taking leadership of the situation. You want the whole team, not just the tech lead or manager, to feel capable of speaking up and sharing leadership for resolving these situations. Use this direct interaction to push that team-driven leadership and encourage the team to be in charge of situations instead of victims of them.

Scenario 3: You're asking because an idea occurred to you, you just heard of another team doing a related task, or you have an unspecified concern about the project and knowing more details will help clarify.

Getting details from the developers directly is often useful when you have an intuition nagging about a project. Again, the trick here is to do it without interrupting a developer who is in the middle of flow. Unfortunately, you're the boss. Even if you try to communicate via non-urgent channels like chat or email, often the person will notice and drop everything. Some situational awareness helps. If you work in the office with them, try to wait until they are getting up from their desk, going to lunch or coffee, or notice when they are out of the zone. If they're not in the office with you, encourage them to make active use of chat status to indicate when they can be bothered or not, or make it clear at the outset of your chat or email that the topic not urgent but you would like to get some details later.

Have you heard of "swoop and poop management?" It describes what happens when a manager or other senior party unfamiliar with the details drops by the team, makes a suggestion for something the team should look at, and then leaves. Swooping down, pooping out an idea or comment, and flying away without seeing the effect of the interaction is, at best, a distraction or annoyance and, at worst, causes people to start focusing on a causal idea instead of the important tasks at hand because The Big Boss said so.

In all of these situations, you want to defer to the team's immediate manager, tech lead, or product manager as it makes sense. Going directly to the team should be an occasional event, not a regular occurrence. It's not that you can't have a relationship with the team directly, but it is the job of the tech lead or manager to manage and communicate project status specifically so that the engineers can focus. When you do choose to go to the team, do it productively and positively. Use it to share ideas with the developers, help them grow as leaders, and affirm your connection with them in a productive way.

Find more of my columns here!Camille Fournierhttp://email@example.com:blogger.com,1999:blog-8221886912876606828.post-2737778286091889012016-04-12T05:11:00.001-07:002016-04-12T05:12:55.698-07:00Ask the CTO: Navigating the hands-on to hands-off transition
I'm writing a new series for managers on oreilly.com. Here is a teaser for my first post!
The problem: I'm a new manager and I'm overwhelmed

A few months ago, I was given the opportunity to run a new team in a growing area of my organization. The company thought I was ready for a bigger leadership role, and I agreed. I think I have a good track record that prepared me well for this: I've been a successful tech lead, had a couple of direct reports, and created some great software. I was excited to grab this chance to lead a large team and set the technical direction for part of the business, so I gladly took the job.

But lately, I've begun to realize that instead of having a few hours of meetings a week, more than half of my time is booked before the week begins. I have regular 1-1s, touchbases with peers across tech, and meetings with the product team for planning, interviews, and strategy sessions, and the list goes on. I was excited to write some code for the new systems my team is building, and I've tried to, but the only time I can find is in the mornings before everyone arrives, or at night after I've eaten dinner. I'm totally stressed out trying to balance all of this, and my team is starting to complain that I am canceling my meetings so I can have more time to code. So, my question is: how do I learn to balance my days so I have time for all these meetings and management tasks, but also time to write code?

The solution: Think of management as real work

Let me ask you a question, before I begin. Do you believe that management is real work? Do you believe it is work that is just as valuable as coding, architecture, and other hands-on technical tasks?

We start with that because if you do not think that management is real work, you will continue to treat it like an unfortunate burden to be dealt with so you can get to the fun stuff. Which, sadly, is the attitude that many managers in tech seem to take. I say that this is sad because it causes not only suffering on the part of the manager, but a lot of damage to the team as well. Your team needs you to be there as a manager for them, and it is almost impossible to show up fully for a role that you don't think is valuable. Management is work, and it is important that you put your management priorities front and center.

Great managers know that their value comes from the ways in which they create functioning teams, focused on the right work. When you can do that job well, you will almost always create greater value to the organization than you would as an engineer; yes, even a 10X engineer. If you shortchange your role as manager by fighting for code to write and technical work to deliver, it's likely that you will end up, at best, totally stressed out, and at worst, slowing down your team.

Sometimes we managers feel that we have to keep writing code because otherwise things won't get done. However, if your team isn't getting enough work done, your job is not to do the work yourself. Your job as a manager is to figure out how to help the team get more done. It is incredibly hard to make the overall team stronger and spend half your time focused on doing the work yourself, especially when half your time is actually overtime. Yes, immersing yourself in the technical details may give you some insights into the day-to-day challenges of your team, but you can also get many of those insights by training your team to notice them, and helping your team know what to tell you.

Going hands-off is hard, even if you do value the work of management, because you no longer have a simple, easily measurable thing to look at. Experienced engineers get frequent strings of wins as they write code, fix bugs, and see new features come to life. The feedback loop as a manager is much, much slower. There's no red-green-refactor for guiding humans. It's okay to mourn the loss of that endorphin hit. You spent years getting good at the job of being an engineer, and now you have to do something that you probably aren't as good at yet. It will get better, but it will not be the same.

Answer continued with practical advice and more on oreilly.com
Camille Fournierhttp://firstname.lastname@example.com:blogger.com,1999:blog-8221886912876606828.post-25929891511200611752016-04-01T09:17:00.000-07:002016-05-03T08:45:14.948-07:00You can bring a horse to water...
Trying to Convince People to Change

I was talking to a friend who was frustrated with one of her engineers. This engineer had a tendency to fall into some bad habits when stressed out, and my friend had given him a book to read on the topic, but he hadn't bothered to read it. Why not read the book, which would shortcut all of these conversations and corrections my friend needed to make over and over?

Are you familiar with this story? I am, having lived it several times. I have given my team various books to read over the years. Some of those books include:

Creative Mission Critical Synergy For Leadership

Turn the Ship Around
Leadership and Self Deception
Making Things Happen
The Five Dysfunctions of a Team

I have even held reading groups for some of these, I wanted so much for my team to read them.

I love to read, and I have grown to love books in the "self-help/business/leadership" genre. These books have taught me a ton, heck, I blogged my defense of the repetitive business book because I find so much value in them. They're great!

However, getting value out of books like these is predicated on two important factors:

1) You have to actually read them
2) You have to read them with an open mind to learn from them

Asking my team to read books has had mixed results. The most successful book I tried to get folks to read was Turn the Ship Around. I read it with my leadership team, and we would discuss it in our team meetings. It is a book that is so deeply applicable to the practice of managing engineering teams that I think it was easy for my team to appreciate its value.

For most of the rest of the books, the people who were already interested in the topics read them, and the people who did not want to change what they were doing did not. Even when the doubters read them, they read them with a mind towards disagreeing with their message, and I'm not sure they got anything out of the books.

This is not a fun lesson, but it is an important one for anyone who is managing a team. You can't force people to want to change. You can give them information, books, classes, coaching, but if they don't see a need to change, none of that will help. So the first thing you have to do, before giving them books, is to really convince them that they need to change.

Ah, but this is tricky! Do they actually need to change? If they change, it will make your life easier. Will it make their life easier?

Sometimes, we want people to change when in fact what needs to change is the situation we've put them in. If someone on your team is acting really negative, do they need to change their attitude? Or perhaps, do you need to move them to a team where they are not being ignored by their manager?

Before you look to change the people, make sure that the change that needs to happen isn't in fact something in the environment that you can control.

Most people are going to behave in unhealthy ways when they are in unhealthy environments. Asking someone to change the way they react to stress is a tall order. Sure, it would probably be good for them to chill out, be nicer, stop blaming others for their problems, but I've been working on my unhealthy reactions to stress for years and I know I still have a long way to go. Even when people want to change, personal change doesn't happen overnight. It is usually easier for a manager to change the environment than it is to change a person's reaction to that environment.

Looking back to my successful reading suggestions, they have almost all come when people had control over their environment, and the book was about helping them drive change in the team. It is pretty rare that I've given an unhappy person a book for reacting better to unhappy circumstances and seen them embrace it.

Poor reactions to difficult situations can negatively impact the team and it's your job as a manager to help people identify these behavioral issues. Books can be great for this, but they are rarely going to shortcut the process of change. No matter what, don't forget to look at the circumstances that are triggering the behavior. It is unlikely that you'll coach your team to Buddha nature but you might be able to reduce the stress that is causing the problems in the first place, and that's a win for everyone.Camille Fournierhttp://firstname.lastname@example.com:blogger.com,1999:blog-8221886912876606828.post-71959637752258709802016-02-24T12:00:00.000-08:002016-02-24T12:00:17.805-08:00Ask the CTO: The Angry EmployeeQuestion:

A few days ago, we had a fairly impromptu team meeting to discuss a new initiative. My goal was to brainstorm some creative visual ideas with the designers, but I also invited the engineering team so that they could participate. One of my senior UX engineers, Dan, was out of the office, and so he dialed in to the meeting because we couldn't realistically wait for a few days and it didn't seem urgent that he attend in person.
We had the meeting, and one of the ideas seemed to touch on some of the things Dan really cared about. The designers were proposing something that in my mind was orthogonal to what he had been advocating, but he felt angry that others were encroaching on his turf. This culminated in a rant on team chat about the situation which upset several of the other teammates, and when I tried to message him about it privately (he was still out of the office) he got angrier and accused me of not supporting him and always siding with the design team over tech. What do I do?

Answer:

Well, there's a lot to unpack here. Seems like a few things that should have been minor issues (team meeting without everyone in the room, one person feeling that others were encroaching on their job) escalated quickly into some serious unhappiness.

Let's discuss what went well. Trying to address the issue of inappropriate venting on chat right after it happened was the right thing to do. Even though chat is not a great way to have difficult conversations, it is always good to provide immediate feedback when you see things happen that are not respectful of others in the workplace. Sometimes the person will apologize immediately, to you and the team. If this happens, you don't need to bring it up again but you do need to watch for it in the future. Unfortunately, this time it just escalated the situation, and instead of an apology you got blamed for creating the frustration in the first place.

The thing to do now is to get face time with Dan. You can take him to breakfast, lunch or coffee if being in a public place seems more neutral than doing it in a conference room or office, but it needs to happen quickly. Letting him cool down for a day before you address the issue again is OK and possibly even healthy, but it is not OK to let this hang out there for days.

Once you get him face-to-face, your job is to listen. Completely. Don't say anything except perhaps murmurs to indicate that you are listening and following along as he speaks. At the end, give him a period of silence to ensure that he is really, truly done saying what he needs to say. For many people, just listening will be the hardest part. But you gotta get comfortable holding silence even when you're bursting to comment.

Now that he's done, you are going to repeat back to him what his concerns are as best you can, and ask clarifying (vs leading) questions. Your goal here is to make sure you understand exactly where he is coming from, and he believes that you understand this. This is to stop yourself from telling stories about him. If you find yourself filling in gaps, "you are mad because you were not in the room because you're always taking days off whenever it suits you," for example, stop. No filling in gaps. No telling stories. No imagining motivations beyond what he has told you. Give him the chance to feel totally heard.

Only once he feels totally heard are you allowed to then offer your interpretation of the situation, and how it differs from his. Try to come at this with a new perspective given what you now understand of his experience. You may find, after hearing him out, that you did screw up and ignore his ideas. If this happened, admit it and apologize.

OK, cool, so you've heard him out, and stated your case. Now what? First, if he has not yet apologized for the chat outburst, that needs to happen. It is not optional. Remind him that, as a senior person on the team, people look to him for leadership, and his behavior was not one of a leader. Beyond that, you need to start talking about why he trusts you and/or the team so little that he felt compelled to dial into a meeting that was really a courtesy invite, and why he thinks that others are stealing his ideas and getting credit that he is not getting. Because people rarely get angry and stay angry after a single minor incident. They get angry and stay angry because they've built up resentment about something over time. This is a strong warning signal to you that something is broken in your team. Even if this person is lost to you, identifying the trust gap on the team and working to repair it is essential for future stability.

A few final thoughts. We sometimes go overboard in trying to get everyone in the room for "brainstorms" and "idea sessions." Inevitably, as your team grows, people are out of the office or worse, you just simply cannot have every single person involved in these decisions. This often feels like a loss of control for early employees or senior folks who are, for whatever reason, excluded. Coming up with strategies that let people have effective idea meetings without having everyone in the room is essential. Remind everyone that ideas are just the barest first step. The path from "idea" to "implementation" usually twists the idea in ways you can't foresee, and there should be plenty of chances for people to help shape them into a better reality even if they miss the inception point.

You may want to triangulate with another person's observations of what happened in the meeting. If you decide to ask someone else about their impression, be careful not to lead them into a story you want to hear. Take the time again to listen instead of speaking yourself. Even if they agree with your assessment that Dan was out of line or tell you that you did nothing wrong, don't use it as a cudgel to bash Dan with. Be especially careful of WHO you ask to share their observations. If you are guilty of favoring designers over engineers and you ask another designer for their opinion, they may back you up, not seeing the problem. Another data point can be useful but it still does not actually paint a perfectly objective picture.

Finally, there's the possibility that you can't handle this alone, that the person is too upset to talk to you 1-1 and you need to involve a peer, superior, or someone from HR as a mediator. If that is the case, steel yourself for what will likely be an unpleasant meeting. Even if you smooth things over, it's going to take some serious apologizing on both sides and a concrete plan to work through the issues that led to this place.

Dealing with an angry team member is always touchy, but as with most difficulty situations, it gives you the opportunity to look at a bigger picture that you might have been missing, and think of strategies to address it. So don't panic, listen, and learn from the situation at hand.Camille Fournierhttp://email@example.com:blogger.com,1999:blog-8221886912876606828.post-88657742483774555092016-02-22T12:00:00.001-08:002016-02-22T12:00:02.737-08:00In Defense of the Repetitive Business BookOver a recent vacation, I finally read Mindset, by Carol Dweck. For those of you unfamiliar with the book, I'll recap quickly. Have you heard that you shouldn't praise your children for being smart, but instead praise them for working hard? That is probably the most popular trend coming out of this book, which discusses at length and in almost excruciating detail why a "growth mindset," that is, one that believes that people can get better at whatever they choose, that effort and exploration are the keys to success, is preferable to a "fixed mindset" that believes that you are as smart, athletic, musical, etc, at birth as you will ever be, and effort is secondary to your measure of natural talent.

Mindset is a deeply repetitive book. You are treated to story upon story upon story of the successful (and happy, and well-adjusted, and sustaining) person who exhibited the growth mindset. You're treated to many contrasting stories of the successful but less-than-they-could-have-been (and unhappy, and maladjusted, and burned out) person with the fixed mindset. You also get a good dose of research to back up the observations of the behaviors of people who both put themselves in various mindsets and people in experimental conditions who are put into the two mindsets. It ends with some situations that you might face, a parent with a fixed mindset child being one, and suggestions for how to approach them with a growth mindset.

I would absolutely recommend that you read it.

You may be surprised, given the faint praise I have given so far. It's repetitive, deeply so. If you get the concept, then, why read the book? You could probably get the gist with a blog post or short article, or maybe a TED talk. What's the value of a book on the topic, beyond lining the author's pockets?

I think that sometimes I fall victim to this fallacy that if I am familiar with the general outline of a concept, and I agree with the concept, that I understand this concept. I see this play out especially in non-technical topics. If I can roughly explain it to someone, I understand it, right?

Of course, there is a huge separation between understanding a concept and putting it into action. Many of the concepts introduced in pop psychology or business books are pretty easy to understand. The problem is putting them into practice. Remembering to do them. Most people understand that the first step to losing weight for most people is to get more exercise and eat better, and yet, putting that simple practice into place is hard. It's hard because breaking habits is hard, forming new habits is hard. Changing the way you react to things is hard.

Mindset is in some ways just a rehash of concepts of Buddhism. Let go of your notion of "self." Be open, relaxed, curious, willing to believe that you can grow. The only inevitability in this life is change, nothing is fixed. That means that, yes, success is ephemeral, but it also means that you are capable of changing, learning, and growing, all the time. Many leadership, pop psychology and business books end up sounding like a rediscovery of parts of the dharma. No one is surprised when you say that, as a philosophical, spiritual, or religious person, you are still learning the meaning of your particular path, and learning every day how to walk that path. It is no surprise that it takes a lifetime of study. So, too, does learning the concepts of leadership, creativity, interacting with fellow humans, and growth. Whether or not it is a spiritual path, it is not something that most of us find natural, and not something that will sink in with an article, or even a book. But it helps to get a prolonged exposure to the idea, to work through some of its nuance, to spend 5 hours with it instead of just 15 minutes.

So, read Mindset. Think about your own mindset. I can say that personally I have moved slowly from fixed mindset to growth mindset over the years. It has been hard. I still fall back in places to the fixed mindset. Why am I moving? Mostly because it's just more fun to grow. To learn new things. To believe that you can change. I kept meeting these people that seemed so light, so free, so creative, and they just seemed so willing to learn and fail and learn some more. Why not me? Why not all of us?
Camille Fournierhttp://firstname.lastname@example.com:blogger.com,1999:blog-8221886912876606828.post-51121419632058137092016-02-15T12:00:00.000-08:002016-02-15T12:00:00.146-08:00FramingI had a realization, towards the end of my last job, about company values. What are company values (aka "Core Values")? Well, here are some examples: Zappos, Etsy, Facebook. My former company had 10:

1. Everyone deserves a Cinderella Experience

2. Dream big and go after it!

3. Make the most with what you have...scrappiness is a virtue

4. Debating, honest conversations and collaborating make the company stronger

5. Happiness and positivity is a choice

6. Embrace the RTR family and bring your authentic self into the office each day

7. Bring your best intentions to everything and trust that others do the same

8. Adapt and learn from everything you do

9. Roll up your sleeves and get involved. Everyone should be accessible and involved with the day to day elements of RTR

10.We are all founders of Rent The Runway

When I first started, I was skeptical about the purpose of Core Values. Zappos, the most famous advocate of this concept, seemed a bit weird. I am not a conformist, and I felt like expecting a diverse group of people to embrace the same set of values and beliefs was a bit Orwellian.

What changed my mind? As part of the company review process, we would ask people to mention ways in which their peers embraced the core values. One person might write, for example, "When Jane suggested we try this crazy experiment to increase the performance of our product page, she encouraged us to dream big and go after it." You weren't required to spell out how each person met every value, just give one or two instances where they had met them.

Is it a good idea to use values as part of the performance review process? Well, for better or worse, one of the things that indicates success within a company is how well a person is capable of working within the culture of that company. This can be a bad thing, when the culture of the company is confused with the color of the company, the gender of the company, the background of the people in the company. That is not a very specific culture, and it is likely to cause bias that does not actually serve to reduce the collaboration issues that you might worry about in heterogenous groups. When company values are more explicit, however, they give you something that is (hopefully) less correlated with how people look and more correlated with how people communicate, make decisions, and behave.

I wrote, read, and delivered many reviews, always involving a section on values. I also observed many "core value stories," where employees would stand up and tell about another person or group who went above and beyond and how that tied back to some of our core values. I got to see over and over again examples of people exhibiting these values and the ways they presented themselves.

At some point, I realized there was a pattern. The people in the company who were beloved by all, happiest in their jobs, and arguably most productive, were the people who showed up for all of these values. They may not have been the people who went to the best schools, or who wrote the most beautiful code, in fact they often weren't the "on-paper" superstars. But when it came to the job, they were great, highly in-demand, and usually promoted quickly. They didn't all look the same, they didn't all work in the same team or have the same skillset. Their only common thread was that they didn't have to stretch too much to live the company values, because the company values overlapped with their own personal values.

What's the takeaway here? Well, we often talk about "culture." By now, we know that beer and ping pong tables aren't culture. Many of us fear that "culture" can be a dog whistle for "people who look like me." And yet, people are more likely to be successful and happy if they are in a company with a culture that matches their values. My experience has led me to conclude that looking for the values of your company as part of your interviewing process is probably at least as important as the technical and skills screening, in finding the best employees.

Why is this post called Framing?

The way you ask people to look for values is going to make a big difference in what they look for, and what they see. You might have 10 values, as RTR did. Would you really want to ask every interviewer for a "yes/no" on all 10? Probably not. But if you boiled that question down to "culture fit", do you think the interviewers are going to think about the company values? Or are they going to think about whether this person looks like them, talks like them, is "a person they could get a beer with?" The way you frame the question of culture is important, and if you aren't explicit, people may skip over the details and go with their bias.

If you agree with me that values are valuable, I encourage you to put them in your interview process, and make them explicit. Don't ask for "culture fit", list the values and ask people to mention any they noticed the person definitely meeting or definitely not meeting. Prime the interviewers beforehand with the list of values, so they know what to look for. And then, let me know how it goes! Because this is still theoretical for me, and I would love to hear your experience, as well as any counterpoints to what I have suggested.

Camille Fournierhttp://firstname.lastname@example.com:blogger.com,1999:blog-8221886912876606828.post-84051944295173465552016-02-12T07:35:00.000-08:002016-02-12T07:35:42.143-08:00What do I do with my time?Question:

I'm a new manager, new to both the company I work for and to management. When I joined this company there were several fires for me to help put out, and every day I was busy dealing with one urgent task or another. But now I'm drifting. My boss doesn't have time to tell me what to do, I don't have any features that I am responsible for, and no one is urgently requesting my time. What is my job, now that things are no longer on fire?
Ah, yes. One of the challenges of management that we don't often talk about is those times when you have no clear urgent tasks. Engineers deal with uncertainty in relatively bounded forms, such as, how should I break down this big project into smaller chunks, how should I architect this system, who should I talk to for information about this feature, what library should I choose? These are enough to stymie some, but usually by the time you've been working for a few years you know how to get started on these types of problems.

Management, however, is a different beast. Management is like being in operations. Operations engineers must balance a series of ad hoc needs (system configurations or permission granting, say), with fires (outages), and long-term strategic projects (moving to a new data center, upgrading a major piece of critical infrastructure). As a manager you also have regular ad hoc needs (1-1s, meetings, small decisions) and fires (hiring, firing, projects in trouble, outages). And you have long-term strategic projects (planning for the team growth, thinking about the next quarter's goals, anticipating future obstacles). Like operations engineers, many managers get really good at the ad hoc and the fires, and really bad at the long-term strategic projects. It's much easier to do things right in front of you than it is to think abstractly about unclear topics.

When faced with the blank slate of empty time and no obvious deliverables, what can a manager do to make the best use of that time?

As a new manager to a new company, downtime is a good chance to learn the existing systems. Learning things that you aren't actually working on can be really challenging, so if it's feasible you might find small bugs to fix or minor improvements to build, things that aren't urgent (in case another fire crops up) but that will give you the feel for working in these systems. You can also use the downtime to meet with other teams that your team works with, learn about their projects and challenges, look at what they're busy with. Lend a hand to their managers, or help your boss fill that gap if they don't have one.

At some point, though, you will have gotten comfortable with the teams, the code, the projects, and you'll still find yourself with downtime. This is the chance to flex your strategic thinking. Take a bigger-picture look. What are you not doing that is important, but not urgent? Maybe it's planning for reviews next month, setting up a team dinner, doing some proactive outreach to candidates you may want to hire in six months, or finishing that presentation that you have promised to give on testing but keep putting off. What are the recurring problems your team is having? What is not going smoothly? What could you be doing to resolve that? Remember, part of your job now is to define what work needs to be done. Your boss won't always be able to tell you what to do, and she probably expects you to tell her what needs to be done. Use this time to answer that question.

Sometimes we put downtime to use in bad ways, and I don't mean procrastination. There are times when the best thing you can do with downtime is take a breath, check in on the internet, watch a talk you have been meaning to see. All of that is better than using downtime as an excuse to make work for other people, which can happen if you're not thoughtful. If you use your downtime to half-bake a feature and throw it into prod for your team to support, that is harmful. If you use your downtime to wander around and interrupt your engineers who are busy working, that is harmful (and yes, I'm guilty of that sometimes!).

You are responsible for finding productive uses of downtime, and part of that is resisting the urge to meddle, micromanage, and distract your team just because you don't know what else to do. Is everything going ok? Are your teams productive, getting things done, working on the right stuff? Great! Use your time to think about the future, write a blog post, catch up on small unfinished errands. Don't worry, there will be another meeting, another fire soon enough. Enjoy it while it lasts.Camille Fournierhttp://email@example.com:blogger.com,1999:blog-8221886912876606828.post-555128668192628632016-01-28T15:27:00.000-08:002016-01-28T15:27:34.067-08:00Qualitative or Quantitative but always AnalyticalI did a panel at Etsy's engineering leadership offsite today, which was amusing. One of the topics of the panel was:
Challenges of balancing data-light product bets vs purely data driven incremental improvements.

All three of the panelists agreed, although each of us phrased it a different way. The first panelist (Dan McKinley) spoke about the need, even for products that are not purely A/B test driven, to drill down on the goals and try to find something to measure about how a project will actually achieve a goal. If the project is part of a larger goal to increase revenue by 25% this year, what way is it contributing to that? How do we measure its success? Even when you are driving decisions by "vision" there is some quantitative goal you are trying to achieve, so state what it is.

The second panelist (Albert Wenger) spoke of the importance of balancing the quantitative with the qualitative. Some things cannot be purely quantitatively measured, and there are qualitative measures that are incredibly valuable to the process of discovering product market fit. User testing, user research, watching how people actually engage with a product are all essential to creating something great, beyond simply finding numbers to measure and trying to increase them.

My perspective on the issue is that qualitative methods are important, but qualitative is still analytical. You may not be able to use data-driven reasoning because you're starting something new, and there are no numbers. It is hard to do quantitative analysis without data, and new things only have secondary data about potential and markets, they do not have primary data about the actual user engagement with the unbuilt product that you can measure. Furthermore, even when the thing is released, you probably have nothing but "small" data for a while. If you only have a thousand people engaging with something, it is hard to do interesting and statistically significant A/B tests unless you change things drastically and cause massive behavioral changes.

So, instinct and guesses are necessary. But we needn't lose our analytical approach just because we don't have data. When you build something, you have a hypothesis about the person you are building it for. You have a guess as to what they will like, and most of the time you have a reason for that guess. When you're trying to build a business, you need a chain of events that you expect could happen that would indicate a product is successful. You have a sense of what to start measuring once the thing is released that will show whether it is working. Answering the questions of who is my customer, why would she use this, and what will signs of interest and engagement look like is essential to going from vague instinct to thoughtful first product.

Data can't make all our decisions for us because data isn't there to get us from 0->1. We have to use our powers of observation, of empathy with our customers, and of deduction, to create smart hypothesis in a qualitative way. Qualitative analysis will always have a role in product development, and customer empathy is likely to drive us more quickly to great products than simply relying on numbers alone.

Thanks to Etsy for hosting and my apologies to my fellow panelists if I misrepresented your views!Camille Fournierhttp://firstname.lastname@example.com:blogger.com,1999:blog-8221886912876606828.post-45255528422894177372016-01-25T10:46:00.000-08:002016-01-25T13:52:31.564-08:00Hiring Engineering Managers: Screening for PotentialI have been in many discussions on the best way to interview and hire engineering managers. Here are my thoughts, having done this both successfully and less successfully, including some things that I have looked for in the past when being interviewed.

First: Be thoughtful about what you are looking for. There are people out there who are looking for the opportunity to go into management. Lots of them, in my experience. These are good people to hire, because many of them will turn out to be good, thoughtful managers. Most of the time I hired this sort of person into a senior engineering role that quickly became a tech lead role. I was explicit at hiring that we didn't have a team to give them immediately but that I would be expecting that as the overall team grew they would move into such a role when it became available.

Now, I should be clear, this exchange requires a lot of trust on both parties, as well as the possibly unspoken assumption that they still have to prove themselves capable of doing the job once on the team. I have turned down jobs that asked me to make this bet, and I would not hold it against anyone who felt that it was too risky. But on the flip side, if you really want to grow your management from within, hiring people who both want to be eventually moving to leadership roles but are comfortable coming in as individual contributors first is pretty essential to making that work. If you want to grow management from within but don't bother to look for people who want to grow into management roles when you're hiring, you may end up with mostly people who just want to code, and that is not good for anyone.

OK, so you're hiring a specific management position. What do you look for?
There are two camps here. The first camp is that you look for incredibly smart tech lead-level developers who may have had limited management experience and put them in the role. They will easily pass whatever technical screens you put in front of them, but hiring is a risk because they may not really be good managers. If this is the way you want to go about hiring managers, you need to spend a good deal of time focused on screening for management potential. Screening for potential is different than screening for experience. Right now, I'm going to talk about screening for potential; in part 2, I'll talk about experience.

Questions to tease out potential:

Tell me about a project where you have acted as the tech lead. What was your role like, as tech lead? What were things you did that were different from the rest of the team? How did you ensure that the project was successful?

What you are looking for: Someone who answers with more than just "I designed the architecture, chose the libraries, and wrote the most technically challenging pieces of the code." They should have taken an active role in the project management, even if there was another person explicitly or implicitly in that role. They should have contributed to predicting problems with the delivery and working with the people on the team or cross-team to ensure success.

When you bring a new team member onto your team, what kinds of things do you personally do as part of their onboarding? Have you ever been a mentor to a new hire or intern? What was that like, what did you learn from it?

What you are looking for: Someone who is actively engaged in the work of bringing on new people, and thoughtful about making that process better. Someone who respected the work of mentoring, who isn't just trying to shed human interactions quickly to get back to code.

Tell me about some things you have done to make the process of writing or delivering code in your organization better.

What you are looking for: Some strong examples of seeing process/people/systems problems and raising their hand to suggest improvements.

One suggestion I have heard, but not tried, is to do a role-playing exercise with the candidate. Set up a circumstance that might happen, such as, an employee is unhappy that they did not get promoted. Provide an overview to the candidate and give the interviewer some details that may include information that the manager doesn't necessarily know. Have a third party observe the interaction, and then at the end of the role play all three talk about what went well and didn't. This could be an interesting tool for hiring either the experienced manager or the potential-driven manager, but I also suspect it is easy on the flip side for it to go poorly if the interviewer isn't good at guiding the roleplay and knowing what to look for. (Credit to Marc Hedlund for this idea!)

Finally, when hiring this type of candidate, you are probably going to get (and maybe even should be intentionally seeking out) someone who is going to not only manage people but drive technical decision-making. Make sure that the people who currently drive technical direction (if they exist) are aligned on that front with the candidate. If the candidate is gung-ho about functional programming and microservices and you are happy in a more conservative technical space, you may end up with someone who wants to make big technical changes that you might not agree with. The team should feel a general alignment to their technical perspective, and ideally people are excited about working for this person because they feel that they will learn something, but don't just hire them as a manager because people are excited about their technical chops.

Overall, when screening for potential, look for signs of stepping up, caring about the people on the team, and thoughtfulness about the processes. In general you should also be looking for excellent communication skills, and everyone who interviews the person should feel pretty comfortable with the idea of working for them. Be wise to potential bias here. The best managers are often overlooked because they don't pattern match to certain characteristics, whether they are "tall and male" or "forceful personality" or whatever. Talk to the team before the interview and give them examples of great managers who sit outside of those stereotypes to reset their stereotype bias a little bit.

When you mishire on potential, it tends to come from overvaluing technical skills + pattern matching on "what a leader looks like", and the failure mode is managers who just don't deliver coherent teams and/or can't deliver projects effectively. Never ever hire a person you feel is overly ego-driven.

One final word on this candidate: If you hire someone for potential, be prepared to train them. They are going to need help. Whether it is formal training or a lot of mentorship from you or a mix of both, no one is born knowing how to manage. I think it is worth sometimes taking a risk on people like this (I'm glad someone did that for me once!) but they will struggle if they have to do it all alone.Camille Fournierhttp://email@example.com