The Colorful and Gray World of Engineering Management

Starters vs. Closers

anita george — Mon, 15 May 2017 02:43:16 GMT

I haven't written a new blog post in a while because my new role has given me new perspective and I am personally learning a lot and organizing my thoughts so I can share them with everyone. One way to describe the change in my role, and what I suspect others have come across, goes back to a question one of my managers asked me years ago, "Are you a starter or a closer?". It's a great question! Think through how you approach work, or even how you approach things outside of work. My answer at the time was easy. I was a closer. I worked in Test or Quality Assurance for decades. I wasn't involved or interested in coming up with new features or starting new projects. The one time I did join a new project during my career as a Test Manager, it got cancelled in 6 months. Taking something that was already being created and doing all the necessary work to make it "done" was rewarding to me. Paying attention to what needed to happen to make it complete, watching that all the details were evaluated and nothing was missed, and getting a piece of software shipped, was rewarding and something that I naturally enjoyed. And then something happened. A few years ago at Microsoft, we combined development (what I consider the starters) with Test (the closers) and I started managing a team that had people from both perspectives. In the first few months, I realized that the "starters" weren't as interested in looking at fit-and-finish items or making sure we have metrics to prove our roll-out would work. They were focused on creating a new system with a new and improved architecture that would make the system more efficient with higher quality. They pulled all the ideas together, did a few proofs of concept, and were itching to get going on this new project. It was refreshing to see. And I started understanding that removing limits, not thinking about rules or restrictions, and just brainstorming about what could be and how to make it happen was invigorating and really fun! And I was the manager of this project so I *could* make it happen. And I did. I became a starter. I moved a bunch of people on to the project, some of who were also closers and made them stretch to be starters. It was really hard work, with many disagreements and a lot of learning. But I wouldn't go back and change that experience because it made me see that you can be a closer, and you can also be a starter. Learning to be both can put new life into your career. And it did for me. I moved into a new role about a year ago to start multiple new projects that weren't much more than general ideas and high level statements. I had to take this ambiguity and turn it into results, which I talked about in my last blog post. I was able to use my new skills of being a starter. And I'm grateful I still have my skills as a closer as well. So are you a starter or a closer, or maybe both? A starter generates new ideas and knows how to turn them into real projects. They talk to people to get feedback and help hone their ideas, they re-evaluate their ideas, change and reform them until they turn into something that is needed and that solves a specific problem, and they know how to rally people to get behind the idea and invest in it. Nothing is off-the-table and no idea is unreasonable at first. It's all considered and what's off-the-table is any rules, limits, or restrictions. Those can be determined later. Closers can watch these ideas turn into projects and then they are really in their element when there is something tangible to play with, poke at, and help put on the finishing touches. They look at the details and are the skeptics. If it gets passed a closer, it's a good project. They understand how to roll-out or launch it, find initial customer reactions to it, and how to keep this new project running once it is available to the public. They review all the details of the project and make sure all aspects have high quality. Now I'm speaking at a high-level, but you can break down the idea of starter vs. closer to smaller tasks and deliverables. Do you have a hard time starting a new task or do you switch between tasks easily? Is it clear to you what the end result needs to be, maybe a document, email, spreadsheet, section of code, or some small deliverable so you can put closure on this one task? I still find myself starting slowly when given a new task and working through figuring out what to do with it takes me a bit of time. Once I get momentum, I can easily move it forward to completion, but getting started can sometimes be difficult (because I spent 2 decades being a closer, perhaps). But I know that about myself and give myself that time because when the momentum kicks in, closing something is easy for me. How about you? Does your work allow you to focus on your strengths as a starter or closer? Can you identify with one of these or struggle to be something you are not? As a manager, do you know who on your team is a starter and who is a closer? You should identify them or ask them and see how they identify themselves. Then make sure they are in the right role based on this. You don't have to be one or the other, as I found out. You can be both, just make sure you know when you should apply one mindset versus the other, otherwise you may never create something new or you may never be able to ship your new project.

Ambiguity Can Be Your Friend

anita george — Tue, 29 Nov 2016 05:35:00 GMT

Six months ago, I took on a new role at Microsoft. I haven't written a blog entry in a while because of all the work I was doing in my new role. I spent 10 weeks as an individual contributor before building a new team and it was a really fascinating time for me as I worked to understand the project that was assigned to me. Was the project well-defined? No. Did I know my priorities? No. Did I have a team with some history to extrapolate from to figure out my course of action? No. I had one simple and general mission statement "make our customers happier". Now go get it done. Years ago, I would have considered this a daunting task. Not because the space to figure this out is large or complex (although it is), but because it is vague and ambiguous. Engineers typically don't like ambiguity. If things aren't defined, then our priority is to go and define them. How else do we build things? You can't build something you can't define. Well, actually you can, but you won't be called an engineer if you do that, you will be called an artist. Ambiguity is a useful tool if you know how to handle it. If allowed to reign over your efforts for too long, your efforts will dissolve because no impact occurred. Things just stayed ambiguous too long so eventually, as engineers, you find a new route, a way to avoid the ambiguity to get to some final result. The unfortunate consequence of this drive for results is that if you allow ambiguity to not have it's time in the spotlight, you miss that deeply-buried idea that only presents itself in the final hours of your ability to hold on to ambiguity. So, what I'm getting at is that ambiguity can be your friend, it can be your freedom to be creative and to generate a better solution than you ever could if you rushed into definitions and priorities. It takes a lot of practice to skillfully master the correct timing around keeping ambiguity in your work in order to produce the best result you can. As engineers, we want to drive for results, and we absolutely should. But if you want to get to that next level of engineering discipline, the one where you solve problems other people would turn away from, you need to embrace ambiguity like it is your best friend. You need to settle into it and let it surround you. It allows you to think out-of-the-box and consider ideas you couldn't if you already had all the rules and definitions in place. And when you let ambiguity be your friend, you can feel better about erasing all those ideas and trying again if they just didn't seem right. On the spectrum, if you go from extremely ambiguous to very ambiguous, back to extremely ambiguous so that you can rethink your ideas, is it really that bad? Many people that go to work every day want to accomplish something so they can feel satisfied when they head home and know that their time was well spent. But what happens if your time was only spent, but maybe not well because what you accomplished didn't meet the mission of your job? What if your team hasn't taken the time to truly think through what the end result should be and the best way to get there? Sometimes the knee jerk solution wins because it gets people doing work and moving forward. Is moving forward in the wrong direction still satisfying? Now, if you are interested in stepping up and managing ambiguity, let's make sure you can identify it correctly. Or let's make sure you know what it is not. Confusion is not ambiguity. Confusion may accompany ambiguity depending on the perspective of the person looking at the problem you are trying to solve. I am currently a software engineering manager working in a quality org acting as a program manager most of the time. To some people around me, that seems very confusing. To me, it's ambiguity that allows me to cross boundaries into each discipline to work on what needs to get done to meet my original mission. But I still must manage the confusion that others have based on their perspective. Confusion is the experience others have when trying to make sense of the ambiguity. Showing no results or doing no work in your job is not the same as having ambiguity. Yes, you can still accomplish things and go home feeling satisfied while managing ambiguity. But if you accomplish nothing throughout the day and chalk it up to ambiguity, you're missing the point. Ambiguity shouldn't be an excuse for inactivity. Ambiguity brings freedom and active creativity. If you are inactive when ambiguity is around, it will get the best of you. And your efforts, no matter how small, will dissolve. You need to have confidence in your ability to manage ambiguity if you want to use it as a tool to drive creativity and move a project forward. You must know when to let it loose and when to start cinching it down. You should determine what parts of your project can keep some ambiguity longer while other parts may need to get clarity much faster. You do need to drive to clarity at some point across your whole project. That's the only way you will get something delivered. At some point, all the ambiguity needs to be gone, like puddles evaporating in the hot sun. And you are left with your very solid, concrete deliverable that contains a ton of creativity and is the correct solution because you let ambiguity stay just long enough to see the positive benefits of it. So, let ambiguity be your friend and don't force it away too quickly with structure and results or you may just miss out on an awesome creative solution.

Are You an Employee or a Founder?

anita george — Wed, 25 May 2016 04:48:14 GMT

If you search on the differences between a "founder" and an "employee", you will see a lot of articles on start-ups, shares of stock, being an entrepreneur, etc. And if we look at the definition of a founder, it is someone who establishes or creates. Ironically, the verb form of the word means to fill with water and sink. I'm sure there are some founders of start-ups that first established and created, and then sank, but let's not go there. The definition of an employee is someone who does work for a business or another person for pay. So with those two definitions in mind, let's take this in a different direction and see how to apply this to corporate life and being an engineer. Well, the first question is, are you an employee or a founder? If you work in a business of any size, your answer is probably that you are an employee. So the more interesting question is, do you act like an employee or a founder? And more importantly, how do you think your answer affects your career trajectory? Many of us are employees by definition and we like the benefits of being employees in a business that is not our own. We don't need to find customers, we don't need to worry about sales and marketing, how to distribute pay checks, and all the other business aspects that you would have to consider when running your own business. But in a corporation, if you truly want to see your career grow, you need to stop thinking like an employee and start thinking like a founder. Treat your company like it is your very own. Now I don't mean go make crazy decision at work because you are going to pretend like you are in control of the company. But what I do mean is that you should take more interest in the direction of the company. A founder cares about the products that get produced, they care about their customers, they care about spending company money, and their work is a part of their life. They don't separate out their work time from the time they aren't at work. In their minds, founders are always thinking about their work, how to make their products better, how to make their customers happier. And then when they are at work, they go make those things happen. If you think like you are only an employee, you are limiting your potential. You'll approach problems as a follower of others instead of a leader. You will miss opportunities where you could step up and be accountable for something important. As an employee, you truly go to work to get paid and to do what you are tasked to do. And maybe for some folks, that is enough. But if you truly want to differentiate yourself from your peers, act like a founder. Care more about the success of the company and not the thickness of your wallet or the time spent doing "work". If you have a difficult time wanting to act like a founder, then maybe you aren't in the right role or even at the right company. If you don't have the passion to make the business that you are working in great, you may want to reconsider your career direction and make a shift in your job (and therefore your perspective) so that you can find an opportunity that will give you the desire to go from an employee to a founder. In the next day, watch how you do your work. How do you approach it? Look for places where you respond to problems like an employee and think about how you may change your response or jump more deeply into a discussion when you act like a founder. Having that added commitment to do quality work and do it for the sole reason of making the company great should help you grow in your career. Therefore, remember to help establish and create like a founder so that you don't fill with water and sink.

Book Review on: "Manage Your Day-to-Day: Build Your Routine, Find Your Focus & Sharpen Your Creative Mind" by 99U

anita george — Sun, 21 Feb 2016 21:03:00 GMT

I recently received a great book as a gift. I'm not one that likes reading fiction. But non-fiction, especially with short, structured chapters is always a winner for me because I can read a chapter during my limited spare time and if I set the book down, next time I pick it up, I can read a different chapter and they are separate enough that I don't have to read them in order or remember details from the previous time. It's called "Manage Your Day-to-Day: Build Your Routine, Find Your Focus & Sharpen Your Creative Mind". I really liked the concise chapters all written by a different person so instead of a book all filled with one person's perspective, I got to read diverse yet similar thoughts across 21 different "visionary creatives" or people who think outside the box and like to write about it. Granted, the title isn't overly catchy and initially I thought this was a time management book, but as I got into it, I found interesting perspectives on how technology and social media has made it difficult to make the time to be creative and generate new ideas. My takeaway is that there is so much input and distractions from media and day-to-day responsibilities that if you don't fight for your own space in your daily schedule, it will easily get filled by other things. In years from now, those other things won't matter. But if you took the time to fill that distracted time with focused time on creative ideas, you could end up in years from now with something that you personally created whether that be business-focused like a new company or website, or art-focused like a new sculpture or painting. Only you can protect your time in order to have the time to do the creative things you love. This book gives you some ideas on how to do this, how to be efficient, and how to have better awareness of how technology has crept into our personal time.

I always enjoy seeing tips-of-the-day or profound sayings that make you think. This book is filled with them and they are good. I'm not one to add a saying to my auto-signature in email, but if I were, it would be one from this book. Here are a few of my favorites:

"It's not the load that breaks you down, it's the way you carry it." by Lena Horne
"What information consumes is rather obvious: it consumes the attention of its recipients. Hence, a wealth of information creates a poverty of attention." by Herbert Simon (renowned social scientist in 1971)
"The difference between successful people and very successful people is that very successful people say 'no' to almost everything." by Warren Buffett, I can see this relating to how to protect your personal time.
"You can do anything, but not everything." by David Allen
"Your mind will answer most questions if you learn to relax and wait for the answer." by William S. Burroughs
"Woody Allen once said that 80 percent of success is showing up. Having written and directed fifty films in almost as many years, Allen clearly knows something about accomplishment. How, when, and where you show up is the single most important factor in executing on your ideas."

I found the chapter written by Scott Belsky to be the most interesting to me. Scott also wrote the foreword and is the co-creator of Behance, Inc. In his chapter, he touches upon serendipity and how putting down our phones in order to experience chance encounters with others may cause a relationship to be formed that could lead to a successful outcome. He states "The greatest value of any experience is often found in its seams". Now, as I run errands or go between meetings at work, I don't look at my phone but instead talk to people and see who I may run into that can help me move forward in an area and be successful. It's the small things like this that may have the biggest impact in my career.

I have never written a book review for my blog, but I get a lot of questions from my coworkers on what leadership books I find interesting. So although this isn't specifically a leadership book, I did find it full of helpful tips to manage my time and my career better so I thought it was worth sharing. I would recommend this book to anyone trying to find ways to be creative because it goes beyond time management and explains how others find different ways to give themselves enough time in their busy schedules to focus on being creative and achieving results. You may find that one of these ways works for you!

Please let me know if you found this book review helpful.

7 Mistakes New Managers Should Avoid

anita george — Tue, 19 Jan 2016 19:53:00 GMT

When you move into a people manager role, it's usually because you are doing a great job as an individual contributor. Being a manager is quite different than being an individual contributor. Instead of only being concerned with getting your own work done, you are now responsible for a whole team of people getting their work done. Without guidance, new managers can run into some pitfalls as they learn what is expected of them. Here are a few things to watch out for if you are new to people management.

Thinking your team members are still your buddies. This catches most people by surprise. You are working in a team and your coworkers are your friends. Now, you are their boss and they are your employees. Yes, your relationship is going to change and you need to come to terms with that. I've seen people try to continue the relationship as it was and in the end it usually results in a few awkward situations before the new manager realizes that he/she is a boss, not a coworker anymore. You build more credibility as a manager if you talk about this with your employees that are friends and come to some agreements. Otherwise, there are unspoken assumptions made on both sides on what to expect from one another that usually don't play out as expected.
Not realizing that you are the conduit of information. Many managers get a lot of information from higher up in their management chain but don't understand that they need to disseminate that information and present it to their team. Managers need to understand when information should be shared and when it should not be. Many times, new managers error in one extreme or the other. They either don't flow information to their direct reports, or worse, they don't filter anything and it all hits their team members. Not only do you need to understand when to filter info to your team, but how. Sometimes how something was said in a meeting with your peers and higher level managers is not the same way it should be presented to your individual employees. You'll have to experiment and make some mistakes in order to understand to what degree you need to filter info and who on your team can handle new information better than others.
Losing your technical skills. Many new managers jump right into managing and forget what got them there, their technical abilities. Granted, the nature of the work a manager does makes it very difficult to keep those technical skills crisp. You spend more of your time in meetings talking to people and when you are at your computer, you are probably writing emails and not coding. Consider owning a small non-critical feature or automation within your team so you have a reason to code. Or schedule regular demos or code/design reviews so you can stay in touch with the technology your team is using and the technical decisions they are making. Even in a non-technical team, you need to stay in touch with what your team is doing at a level potentially a little higher than you were at as an individual contributor, but not so high that you've removed your ability to talk intelligently about the work your team is doing or evaluate your team's skills.
Caring too much about your employees' well-being. Every manager should care about their employees, but as a manager your job is not solely to keep your employees happy. You have budgets to meet, schedules to adhere to, pressures from dependent teams, and a lot of other things that at times may make your employees less than happy. You may need to give them critical feedback, ask them to work on something that is needed instead of their pet project, or ask them to work with someone they would rather not work with. That's ok. Your first responsibility as a manager is to run the business of running your team. Caring for your employees' happiness fits in there, it's just one of many priorities you have to juggle. Be careful not to make it the top one or you will find yourself becoming a very stressed out manager. Given that, if you aren't thinking at all about your employees' well-being then you have gone too far to the other extreme and you need to start thinking about that while managing all of your other priorities.
Being overly concerned about your employees making mistakes. Letting your employees stretch and potentially falter is a good thing. They will learn from the experience and becoming stronger employees. Just do this within a controlled setting so you aren't playing damage control for large mistakes made by your employees. It's good to play interference so your team can stay focused on their work, but sometimes letting them gain some visibility into what you are protecting them from can allow them to grow and allow them to have a greater appreciation for the work you are doing. You shouldn't be so protective and cautious that your employees find it difficult to do anything without your involvement. That's not job security. That's just a lot of unnecessary work that will burn you out as a manager and it doesn't help your employees grow their skills.
Thinking morale events really improve morale. Ok, I'll be the first one to say I'm not very good at holding morale events for my team. I don't buy into the notion that taking a bunch of people to a movie is really going to make them so happy that they will perform better. And do people really enjoy going bowling? Sometimes, the best morale boost comes in the form of genuine recognition for a job done well. Showing appreciation and saying they did a good job beats bowling and a movie any day in my mind. What you'll find with team events is that many will opt-out and if you make it mandatory then how is that boosting morale? If not everyone is there, does the team truly get something out of it? So make sure the event has a low bar of entry and involves personal interaction. Taking your team out to lunch is always a good idea.
Taking the easiest route when making a decision. It's great when the easiest route is also the correct decision, but the majority of times, this isn't the case. When making a decision, don't assume that picking the easiest option will be the right choice. Sometimes, you may get some big wins early on from that easier option, but long term, that choice may come back to haunt you. Consider all your options and force yourself to be open-minded, even to the craziest of ideas presented to you. When you make your decision, make it with the future in mind, not the present. You can always figure out how to get it to work for you in the present, but correcting something much later after the team has settled on it and gotten comfortable with that choice is so much harder than making that hard choice to begin with. Unfortunately, the best way to learn this is by experiencing it. It's ok to change your mind and move your team in a different direction if you realize that a previous decision was the easy one and not the right one. Fess up to it and be a role model to show that doing the right thing is most important.

Don't be too hard on yourself if you make mistakes as a new manager. Learn and move on. Be reflective and try not to make the same mistakes over and over again. You aren't going to wake up one day and say, 'finally I know everything there is to know about being a manager'. It's an unattainable goal. All you can do is be the best manager you can be. Learn from your mistakes. And read a lot of management books over the course of time because many contain great advice and what may not apply to you at one point may absolutely apply to your situation years later.

And if you ever figure out a really good morale event that everyone enjoys and it truly builds morale, please let me know. :-)

Stop Hoping for Quality and Just Test It!

anita george — Thu, 19 Nov 2015 20:09:00 GMT

As I continue to apply more engineering rigor to the release process in my team, I hear statements referring to engineers being hopeful and hoping things will go well. Hoping is not the correct way to ship software. I also hear a lot of statements like “we are confident this will work”. Confidence, although great to have as an engineer, cannot solely be the main indicator to release high quality software. What you need to ship high quality software is testing. It’s having the data that shows you ran appropriate tests and validated not only that your software works when it should, but that it works correctly when it shouldn't, when you take an erroneous path through it, and it fails gracefully if necessary. My team has incorporated an extra check to make sure we truly are ready to ship our software when we think we are. We call these extra checkpoints Release Review meetings or Go/No-Go meetings. Think twice before saying you are confident because it may come across like you are trying to sell the fact that the software is ready to release. But this is not the place for a sales pitch. The people needing to give the positive votes in a Release Review meeting don’t just need a statement of confident. Along with it, they need to see the data to back that up, that proves all the correct items were tested and that proves the software works as expected. I see many confident and hopeful software engineers working late nights and weekends because their confidence and hope was short-lived and inappropriately placed. Please don't be one of them. When we were all learning how to program and how computers work, one of the first things you learn is that the computer, and specifically the software, only does what you tell it to do. If you incorrectly tell it to do something, it will. Software can’t figure out your intentions. It doesn’t have a mind of its own and it doesn’t think “hey, I’m betting my programmer really wanted to do this and not that”. (Although some day it would be great if it could!) Hoping your software does something is a programmer's way of assuming the software understands his or her intentions. The only way to know if your software is doing what you want it to do is to test it. You can’t hope and you can’t push your confidence as a programmer at it. You can only test it. Walk through the customer scenarios. Walk through the places where things could fail and make sure it fails gracefully or recovers without failing. Figure out what you are missing, where your program can fail that you haven’t considered, and then test that and see what actually happens. Where is your program going to fail? You should always ask that question. And if your software is large and complex that can be a hard question to answer. So consider asking yourself where are you taking risks? And what I mean by this is where are the areas in your software:

That have dependencies on code outside what your team owns
That have some code that is unstable and is known to produce a lot of defects
That have some code that is a bit unknown due to it being legacy software, written by people who no longer work on the team and didn’t comment it well
That have some code that is written in a complex way that makes it difficult to understand
That don't have enough testing coverage
That when released, there is no way to rollback or fix forward your changes if problems occur

Communicating risks is hugely important in understanding the state of your software. Understanding the risks early leads to people taking action to mitigate them and that leads to better software overall. Communicating risks within your code is not a sign of weakness. It's a sign that you understand all aspects of your very complex software system and you have the confidence as an engineer to state where the gaps are. Good software engineers know how to test their code for quality and how to communicate the risks and gaps in their software ecosystem. If you have read this far, I'm going to assume this topic interests you so let me ask you to do a little assignment. When you are at work, look at your feature, user story, or overall ecosystem and come up with 3 risky areas where your software may fail. Rate the areas as high, medium, or low. And then determine the best way to mitigate those risks. Do you need to refactor your code, remove your unnecessary dependencies, or do more testing? Now go talk to a coworker about the risky areas you uncovered and post your thoughts in the comment section of this blog. Is it difficult to find 3? Is it difficult to determine what a risky area in your software is? Did you find this exercise easy? I'd love to hear from you. Please add a comment letting me know if this assignment was helpful.

6 Ways for Engineers to Connect with Their Customers

anita george — Sun, 08 Nov 2015 18:27:00 GMT

Satya Nadella's strategy for Microsoft is "Mobile First Cloud First". That's helped keep teams inside the company stay focused on the right objectives, but it only describes the "what" and not the "how". For the how, we should think "Quality First Customer First". Quality can mean a lot of things and I listed out some testing aspects in my last post. In this post, I'm going to go into more detail around the Customer First aspect of Software Engineering.

Who are your customer?
To have a strong engineering team, you need to going the extra mile to understand your customers. The complexity in any IT department is determining who your customers are. Many of the services we provide are based on requests from our internal company business group (groups like finance, marketing, sales, etc.) or they are based on the need to provide efficiency and gain higher productivity with our internal engineers and employees. When your customers are internal to your corporation, it can be confusing on who you are trying to please. For example, if your marketing team wants your team in IT to create a company homepage in order to market your company's products better, are your customers the people in the marketing team or the customers external to your company that come to your company's homepage to buy your products? Let's make this easy. Your customers should always be people external to your company, people who potentially will spend their own hard-earned money for a service or product your company provides. Those "customers" who are in the marketing teams or any other business teams, well, they are just your coworkers. They don't make money from the work you do. Like you, they help make the company money from the work you do. Yes, you need to work together and be really clear on what needs to be delivered, but in the end, your customer is your company's customer whether you are in an IT department or not.

What do your customers want?
If you are a software engineer who understands your customers well, consider yourself lucky. I find that one of the hardest things for engineers to figure out is what their customers want and how to create it in a way that appeals to a large customer base. Engineers need to think about 3 types of customers:

Those who are new to using your service or capabilities and how best to onboard them
Those who use your service or capabilities regularly and have feedback and input that you should be collecting
Those that have problems with your service or capabilities and you need to make sure you have a clear path for support in order to hear about their blocking issues and fix them

How do you learn more about your customers?
The Inside-Out Method: So how do you connect with your external customers in the 3 categories I described? I posed this question to the engineering leadership community within my organization and got some interesting answers. What I found most often is that engineers want to engineer a way to connect with the customer. This is the inside-out way of thinking about customers. What I mean by this is the thinking starts with things that are happening already inside your team (inside the company) and extend those ideas out to reach the information out there (outside your company) that can be used to understand your customers. There are a few different ways to approach this.

1. Telemetry and Flighting: You can focus on telemetry and instrumenting your code to collect usage data on all the capabilities you provide to the customer. Gathering, analyzing, and reporting this data will gain you insights into what your customers are experiencing. Flighting features to a smaller segment of your customer base and using telemetry data to see how the customers are using those features allows you to experiment and tweak features to make them the best for your customers.

2. Quality of Service: Focusing on overall quality of the service your customers are using is very important. Engineers should measure key metrics like MTTD/MTTR (mean time to detect/mean time to resolve issues in Production). As an engineer, spend more time being involved in troubleshooting issues in your production environment so you can firsthand see how your code is being used and where it may be breaking.

3. Integrate customer into your process: If you are using the agile methodology, create user stories and tasks to track standard items that will help keep the focus on the customer as part of your sprints. Add acceptance criteria specific to customer needs. In my team, we have a set of Engineering Fundamentals focused on the customer and that show up as tasks for every sprint.

The Outside-In Method: Next, consider some outside-in ways to understand the customer more. Unlike the first, this approach doesn't look at typical engineering work with a customer filter on it. This approach actually doesn't consider engineering at all but looks for ways to understand what the customers are actually experiencing with your features and services through a change in mindset and internalizing the customer experience. There are some activities all engineers should do to get closer to your own customers.

4. Be the customer: You should dogfood your own products. What I mean by this is use what you are creating and be your own customer. This will help expose issues your customers may have when onboarding to your service or using it in their normal routines.

5. Know the customer: Go visit a customer and watch them use your product or service. Sometime you'll need to go to them, but sometimes you can bring a set of customers onsite for a usability study. This allows you to see how regular customers use your features, and gather input from them. Also consider hopping on support calls. Listen to how the customer has problems using the feature or capability that you created. Talk to the support engineer to find out what changes or new capabilities are needed to reduce customer call volumes. This can gain you a lot of insight into that third segment of customers I mentioned earlier, the ones that use your service but have blocking issues. Finally, consider going to conferences and seminars that your customers attend and ask them questions about their experience using your product or service. Stepping away from your computer to talk to your customers can be a huge learning experience for any engineer.

6. Competitors: Understand how your competitors handle their customers. This is similar to being the customer because there may be cases where you are a customer as well as a competitor. For example, in the software industry, it's easy to see how other software companies handle their customers. As a customer, apply your learning from your own experiences with software to the software you are creating.

As you work through all these items, look for ah-ha moments.
What I have found is that there is a great way for an engineer to truly internalize and understand the customer and that is by having that "ah-ha" moment. That time when the engineer is being a customer themselves and having a poor customer experience or an awesome one. They can't engineer their way out of it. They feel the frustration or the joy as a customer. This can happen a few different ways. Consider having your engineers do an exercise to walk in the customers' shoes. Ask them what the customer would want to see if they came to your company website. I tried this exercise with some of my engineers and some came up with items like showing our customers the company customer satisfaction rating or the throughput of the service. Why would a customer want to know that? When I go to buy something on amazon.com, I don't care how many other people are buying things on amazon right then or whether they are pleased with what they found. I just want to buy something. Don't get caught in thinking like an engineer when you are trying to think like a customer. One of my engineers had a difficult experience at a bank doing a wire transfer and was able to relate it to his own job and had that "ah-ha" moment. In the day-to-day routine of any person, including engineers, you can find times when you are a customer and you can see how this relates to your own customers.

Telemetry data, owning tasks in a sprint related to the customer experience, or talking to your customers can be helpful. Figuring out how to get your engineers to their ah-ha moment is powerful as well. Once they internalize the customer experience and their awareness increases, they will look at everything they do at work through a new lens, the lens of the customer. To understand your customers and how they use your software, you have to experience it, not engineer it.

Quality First

anita george — Tue, 20 Oct 2015 21:10:00 GMT

Whether you are a developer, a tester, or in a combined Software Engineering role, understanding the fundamental thinking behind testing your own code is of significant importance to producing solid, quality services for our customers. Due to this, I'd like to spend some time directing you to some of my previous blog posts pertaining specifically to testing and quality. Interestingly, as I read through these posts, I found them to be timeless and give an interesting perspective that everyone should consider. This isn't training on how to be a tester, but instead some different ways to think about testing through examples and analogies. Enjoy!

Everyone Wants to Test - I was asked what should new testers think about when starting to test software. That question has many different answers, but this post specifically focuses on other activities that you may do and not even understand the tester mindset you apply when doing these tasks. My hope is that this post shows you how everyone has a little bit of tester inside of them. If you have more than you thought, leverage it!

Automation Maturity - What Should an Engineering Manager Focus On? - This post isn't just for engineering managers but for anyone involved in writing automation. It explains what minimal automation looks like and also what too much automation is like and what problems that may cause. Interesting insight for engineers involved in automation creation.

Should BVTs pass 100%? - It's a more difficult question than you think. Granted, I explain some extreme cases where it would be ok to not pass 100%, but for most projects this post is great at explaining why 100% pass rate is expected.

What's Your New Currency? - Moving from Waterfall to an Agile methodology along with thinking about dev and test as a similar role means a need to rethink the value we place on finding bugs. It's actually ok to experiment and have bugs in your production systems if you have the correct infrastructure in place to monitor, fix-forward, and still limit bug exposure to your customers. Read this post to understand more about why bugs are being redefined.

Don't Fall Asleep with Geckos - This is one of my favorite posts that makes a point based on an analogy from one of my vacations. It's about having critical thinking skills always and not getting to comfortable with adapting to a team or a feature set because you can add more value by questioning the oddities. It's another way of testing without being a tester, just change your lens when looking at a solution and you'll uncover things beyond what is apparent..

It's Not Over, Till It's Over

anita george — Thu, 28 May 2015 22:09:00 GMT

The word "over" can mean a lot of positive things. "Over the rainbow" is where you find your pot of gold. "Turn over a new leaf" means you're changing your ways or stopping a bad habit. And "head over heels" describes falling in love. Yet, the word "under" usually means something negative. "Getting under my skin" means that you are bothering me. "Under the gun" means being pressured to get something done in a short amount of time. And "sweeping it under the rug" means you are hiding something that is dishonest. Ok, I'm done with my little lesson on clichés in the English language. How does this all apply to engineering and working on a software team? Well, given the above examples, it's natural to believe that anything that involves the word "over" is good. But that's not the case. Years ago at Microsoft, we had a list of competencies to describe behaviors and traits people need to have to be good at their jobs. Some examples of competencies are confidence, results-driven, and conviction. In moderation, all these are great to have as an engineer. But along with each description of the competency, there was also a description of what "over-doing" it looks like. Someone who overdoes confidence is probably a bit arrogant. Someone who overdoes results-driven may leave "a wake of dead bodies" (another cliché for you) in order to get results, meaning they don't think about who they leave behind or what damage they inflict on the team morale to get results. Someone that overdoes conviction may be so passionate about an idea that they can't think beyond it or listen to others' points of view. These are just a few examples of competencies and how over-doing them can lead to a weakness and not a strength. Another item that may seem positive but really isn't is "over-functioning". Many times, leaders will say 'go do what it takes to get the work done'. Again, within moderation, this works well and if it promotes teamwork then that's great. But be careful when you cross role boundaries. There's a right time to do this to make sure your team is successful. But if you always cross those role boundaries and do what other people in other roles should be doing, you cause a dynamic in the team that adds more confusion than clarity. Everyone counting on you to over-function can cause you to burn out. Also, if you over-function to the degree that you aren't doing your own job because you are filling in the gaps of someone else's role, then you not only hindered them from being successful and exhibit the skills within their role, but you aren't exhibiting the skills within your own role. Crossing role boundaries when needed is an acceptable thing to do. But continuously over-functioning and doing what others should be doing can actually hinder your career. Finally, there is "over-thinking" and many engineers do this. I catch myself doing this. You want things to be as perfect as possible. So you test every possible outcome, come up with every possible scenario, or plan for every possible situation. Someone who does this can get stuck in this cycle of never having things be good enough to move forward. Or they think so much about something that it slows down the process. In an agile team, over-thinking can really slow down the speed of a sprint. That doesn't mean the solution is to just not think and do things quickly. Once again, moderation is good here. Think just enough, plan just enough, think through your tests and your scenarios enough to make the customer happy, but don't over-think what you are doing or you could end up spinning on something longer than necessary. So those are examples of why "over" can sometimes be a bad thing in engineering even though it can be a very positive word. Does that mean "under" can be a good thing in engineering? No. I can't think of any regular task that you could do less of and have it be good. Don't "under-do", "under-function", or "under-think". That will definitely set you up for failure. Better to just focus on moderation. Or maybe all of this is just water under the bridge.

Clean Up Your Campsite!

anita george — Mon, 27 Apr 2015 20:27:00 GMT

I always feel like a responsible adult and global citizen when I go camping or hiking and follow the rule on "leaving no trace". So why do we not do the same thing as engineers? As a camper, I spend time setting up my tent and sleeping bags, organize my picnic table and fire pit area, and enjoy using the whole campsite. But when the weekend is over and it’s time to leave, everything gets packed up nice and neat. I make sure there’s no garbage laying around and that the fire isn’t still smoldering. If it’s been raining, it sometimes takes as long to pack up and keep things clean as it does to set things up. But it's worth it to know that I left the campsite in the same condition that I got it.

As an engineer, it takes time to set up our environments. We have to think about what we need it for and if we need one box or multiple boxes (nowadays, even though we call them “boxes” or “servers”, they really are VMs “virtual machines” and are usually "in the cloud”). We install all the needed components and image or take a snapshot of the VMs whenever it’s appropriate. We do development and testing on our new environments throughout the sprint. Then the sprint is over, we swing into planning for the next one, and repeat this over and over again. This works well when we continue to use the same VMs. However eventually, we may forget about all the VMs we created as we move into new sprints, start developing new features, or even as we move to new project teams. Only on rare occasions does someone think about cleaning up their environments. And that doesn’t mean just removing the older version of the code and replacing it with newer features, I mean actually decommissioning the whole environment. It’s so easy nowadays to roll out new environments that this should be a very dynamic landscape with new environments popping up all the time and older ones getting shut down just as quickly. You don’t need to secure a bunch of servers in the cloud. You won’t lose them (unless of course you secure a bunch of servers and over time forget what you have). The cloud makes things scalable so hoarding isn’t a feasible option and is totally unnecessary.

Why don’t we treat our engineering environments like campsites? When you are done with your sprint, or project, or job, you spend some time cleaning it up and removing any trace that you were there. Leave the cloud (or your data center) in good shape for the next camper.

Leaving these remnant VMs around costs money in some form whether its power and cooling or a staff of people to support them. The cost is real. If you aren’t ready to delete your environments, consider turning them off when you aren’t at work. For us old-timers, turning off VMs just isn’t something we ever considered. And unlike the days when booting a server would take a lot of time or when the only reason you ever had an environment was to run automation through the night, now people are using VMs in the cloud as their “desktop workstations”. So similar to turning off the lights when you leave a room, turn off your VMs when you go home. Be a responsible global citizen and save some power and some cost by thinking about the environments you have and delete or turn them off when you can.

Clean up your campsite and don’t let your campfire smolder.