The endless list of topics that interest me |
Software Leadership
I’m a software manager, now what?
CodeMash 2013 - Becoming A Software Strategist
I was recently fortunated enough to speak at CodeMash 2013. For those who don't know what CodeMash is, it's an amazing software conference held each January in Sandusky Ohio. Here's the slides for my talk for any of you who requested them. |
| Attachments:
Becoming A Software Strategist.pdf
Management - The Graveyard for Software Developers
So your skills have degraded, you can’t type as fast as those younger guys, they can work all night, but unfortunately coffee just makes you have to pee a lot. Not to mention your spouse is sick of you working all the time anyway. Then they offer you a job as a manager and you jump at the chance. I mean, at least you won’t have to look silly, some old person trying to keep up. You’ll be more like a parent and they’ll be your kids. I mean you can still keep your skills up by writing some code on the team, just not as much. You still have a few things to teach those kids and now they’ll have to listen to you. Sound familiar? Although it’s an exaggeration, it’s not that far off from the experience of many software developers turned manager. Unfortunately, I believe this scenario is exactly the reason that so many software teams are under-performing. How often have you caught a manager talking about software development topics? “Here’s how I would solve it”, “Have you considered...”, or the dreaded “I was looking through the code last night and ...” I first encountered this phenomena a long time ago. I was fresh out of GMI, working for General Motors when one day I had the opportunity to talk one-on-one with an executive. This was a man who headed up the engineering side of our entire division. Like myself, he was an electrical engineer. In our 30 minute meeting, he spent about half of it proving he still had the stuff to be a great engineer. He even went so far as to say something like “I could walk out of here today and go right back to designing great hardware”. Maybe he was right, I don’t know, but what has bothered me ever since is how he didn’t seem to be at all proud of his role as a leader. This man had hundreds of people who depended on him every day. His leadership would go on to make the difference between our division succeeding or being spun off and eventually closed. Yet, for him, it was all about the being an engineer and not about being a manager. Here’s something that many of us don’t understand: Management is actually a profession. Management is no less easy to master than software architecture or software development. In fact, because it can sometimes be much less objective, it can be much more difficult to truly master. People who can’t learn their discipline, apply it, acquire feedback, and repeat, will fail in any profession. Management is a full time job, it’s not a hobby and it’s not a retirement package. Here’s some key points that I try to follow: Don’t be a hack How many of us have had bad experiences with Hack developers? You know, the developer who will learn just enough to get the final result out, but then leaves a mess for someone else? How about developers who won’t reuse off-the-shelf code, best practices or patterns? When you discover something in source control, called: “BobsHttpClient”, how do you react? I have the same problems with Hack managers. Management is a full time job with lots of homework. It’s fun to get right, but it takes time and effort. Just as with software development, you can’t just take a class. You’re going to have to bear down and become a manager on purpose. Also like software development, management is a quickly evolving field. Every day people are studying and writing about ways to improve the management of people, projects and processes. Keeping up is hard work. Build a strong team Your team is actually the most important thing. You won’t always realize this. You’ll find yourself spending time on lots of other things, especially with your management and peers. At the end of the day though, how your team performs defines your success. Everything you do should be done with an eye as to how it effects your team. Projects are ephemeral, but your team is not. You need to help your programmers grow into the best possible team. Find regular, effective ways to build their skills and their ability to work together. Don’t depend on a hero or two, your whole team is the point. If you are always improving the engine of production (your team), then no matter what the business throws at you, you’ll be able to accurately predict when your team will be able to finish it. Make small incremental changes As with software you can’t just read the book and start doing something brand new. You need to know if this is a good idea for your domain, if it’s just a fad, and if the idea is something you could implement. If quickly making large changes in software is a bad idea, then making large changes in organizations is a really bad idea. You’ll be making cultural shifts that have an effect on everyone around you. Your direct reports, peers and management will all need time to adjust. As with software, figure out where you want to go and then introduce step-by -step changes. Stop along the way to reevaluate and course correct. You’ll discover it’s surprisingly easy to make changes this way. Good Process favors people One of your primary responsibilities will be to define and enforce process. Good process favors people because it eliminates the mundane and allows smart people to focus on the real work at hand. Good process bring predictability to those tasks that don’t require on-the-spot creativity. Developers should never have to figure out what to do with a new customer request, how design should be communicated or how software makes it into production. You don’t want developers to have to continually bring their creativity to tasks that should be more or less repeatable. Reworking how to accomplish basic tasks wastes time and more importantly, it reduces predictability. Make it your concern to reduce the number of tasks that don’t have a cookbook approach. You’ll find that you both improve moral and increase productivity. Measure everything you can Benchmarking is a highly effective way of showing and improving results. Find consistent ways to measure team performance and the effectiveness of your processes. Bake the measurement and the reporting of the data into your process. Not only will this help you to improve and to know what to improve, it will impress the heck out of your boss. Solicit Feedback You need a consistent, repeatable way of soliciting feedback. Management is leadership and as a leader, you need to be effective. If people think you’re a jerk or a wimp, your effectiveness will suffer. Feedback like this is not as objective as benchmarking, but it allows you to insure that your behavior isn’t completely off the rails. Attempt to solicit feedback, in the form of a 360 degree feedback, from you team, your peers, and your management at least every 6 months or more if you are really struggling in some ways. Forgive yourself You’re going to screw up and fail miserably. If others don’t forgive you, that’s something you can live with, but if you don’t forgive yourself, that’s something you can’t live with. Don’t let mistakes define you. Learn from them and laugh about them. When others make mistakes, recall your own and share them. Learning from your mistakes is the right approach. Try not to bury your mistakes, but expose them to the light of day. Talk about them with your boss or mentor. Most importantly, move on from them. |
It turns out I would make a good Kindergartener
I know you are thinking: "I already knew that Bill". Yes, you may have, but now it's been officially validated by the experts at Menlo. They've called me back for my second interview. You may have read about my first interview at Menlo. If you did, you know how nervous I was and how important it was that I played well with others and didn't run with scissors. Now, I'm heading back to Menlo to spend a whole day. I'll work on a real client project, paired with one Menlo developer in the morning and with another Menlo developer in the afternoon. I'm pretty excited, I just hope I can remember to put away my crayons at the end of the day. |
My Extreme Interview at Menlo
Those folks at Menlo are weird. No question about it. Yesterday I went for my fifth visit to Menlo, but yesterday was different, yesterday I went to Menlo in an attempt to join their team. Previously I had just been curious, trying to understand why Menlo was successful at Agile when so many others had failed, including myself. The people at Menlo are incredibly generous with their time, so over and over again I was able to attend a variety of events, see Menlo in action, and learn about what makes them different. Somewhere between my 3rd and 4th visit I realized that I really wanted the chance to work at Menlo. So they set it up! They invited me to participate in their Extreme Interview process, the first step to joining the Menlo team. I was incredibly nervous, I can't remember an interview that made me so nervous. I guess I really wanted to succeed more than I realized. When I arrived, each of the four tables was full of candidates. There where 16 in all, but other than myself and one other person, the others were Mock candidates, part of a program called Shifting Gears. The Shifting Gears folks were there to improve their interviewing skills by experiencing a completely different kind of interview, the Menlo Extreme Interview. It kind of blew me away. I mean, the interview and subsequent dinner (provided by Menlo) and discussion were well over 3 hours, with 9 Menlo personnel, with really no gain to Menlo at all. I sat down in an empty seat and immediately all three of the Shifting Gears people at the table started talking with me; "Who was I?", "What did I do?", "Did I live around here", "What was Menlo all about?". Boy did that help with my nervousness. I had a supportive, friendly, and cohesive group that I would be interviewing with. Per instructions, I had read the Menlo white paper on Extreme Interviewing and two Menlo blogs that also discussed the process. In my opinion, the goal was to show how well you paired with some one else in a problem solving exercise. I was nervous. I really didn't know how I would do. I'm used to working by myself and pretty much doing everything on my own. I had rejected pairing many years ago and it was only in the last few years that I had really started approaching it again. We were given a brief tour of the Menlo factory, all I wanted was to get started, but I tried to stay calm and not worry too much. I even enjoyed what was now my fifth tour. After the tour, the same instructions that the blogs and the white paper had given, were given again. "Make your partner look good" was repeated several times. We were to perform three exercises, each twenty minutes in length. For each exercise we would be paired with one other person who we would sit next to. Across the table would be an observer. We should ignore the observer unless we had questions about the specific exercise. For each exercise we would have a different observer and a different partner. We would have one pen between the two of us. "Share the pen" was strongly impressed upon us. So it began. Randomly assigned a partner and an observer, I sat down at the number 8 spot. The instructions for the exercise had been given verbally before we started and they were also printed at the top of the exercise sheet. My partner and I introduced ourselves and we sat down to read the instructions, silently to ourselves. It was too quiet and I was so nervous I couldn't remember the verbal instructions, nor for some reason could I actually comprehend the words I was reading. I believe the silence stretched on for days, but no matter how hard I tried, I couldn't comprehend the instructions. I was certainly panicking, but then my partner rescued me. He started asking me questions. I couldn't answer his questions, because I couldn't really remember my own name at that point, but the more he tried, the more I realized that I knew this stuff! The exercise involved us identifying, from a large pool of "Stake Holders", five stakeholders that we would want to interview to better understand how to design a particular software application. The application was an electronic form of the Menlo paper process, similar to Version One or Agile Zen. All we really had to do was to identify good potential users of those products and we were done. It all finally snapped into place, but now all I wanted to do was grab the pen and start circling the right people to interview. I made a grab at it, but again, my partner saved me. He didn't understand at all what needed to be done. I knew that if I left him behind, I would have failed completely. Realistically if it hadn't been for him, I never would have snapped out of my panic, I certainly couldn't let him feel stupid after he had saved me. He was a finance and accounting person, he had absolutely no idea about planning tools, but he did know Microsoft Office, so we used Excel to try to clear things up. As 15 minutes went to 10 minutes to 5 minutes we worked through the kind of metaphors that would help us to jointly understand who would be the right people for us to interview. Lucky for us, the Menlo board was right behind us so we could talk about the product itself in a visual manner. As the last few seconds ticked by, we were able to complete the first part of the exercise, together as a team. We of course never made it to the second part, which was to come up with interview questions, but as far as I was concerned, it was a great success and my brain was finally working again. At the beginning of the second exercise, I was assigned the same observer. Our instructions were to stay standing if we had the same observer or the same partner. My observer handled it all very quickly and as I was in a pretty happy state, this didn't throw me at all. My second partner was an engineer and although English wasn't his first language, he was easy to understand and was very serious about solving the problem before us. We were presented with a number of story cards and instructed to prepare three iterations from the story cards. My partner was a fast reader and quick to make up his mind. I was worried a bit that I was letting him lead too much, so I started using simple interrupt patterns and questioning strategies (thank you Sandler) to get him thinking a bit more about the choices he was making. He was also holding the pen, but the exercise was such that we either needed to share the pen or we needed two pens. Luckily for us, there was a second pen on the table (not sure how that happened). I reached for it, but my partner was quicker. He said something like "Oh, we shouldn't do that". He then looked at the pen in his hand and handed it over. It was a breakthrough moment. We were partners from that point on, quickly and methodically working through each story card. We were so quick that we even had time at the end to re-arrange our iterations and perfect them a bit. The third exercise was just fun, my nervousness was gone and I was assigned a fantastic partner. My partner was a sales person and as so often it turns out, they are some of the easiest to get along with. We were instructed to create Unit Tests within a set of scenarios. I only had one strange moment here where I just started writing after saying what I thought the answer was. Luckily my partner was very engaged and as I had done with my second partner, he slowed me down and got me to talk about the answers before I just pushed on. We laughed about our answers and even pulled out an iPhone to help us figure out one of the tougher problems. I felt completely comfortable and was actually a little disappointed when the exercise ended. Typically, after the three exercises, we would all go home, but Menlo was trying something different. This time, we would all be given our feedback from the observers live, in front of the whole group. I was both happy and extremely worried about this. Worse, they made us eat dinner first! I couldn't believe they were going to drag this out. I had a bit of dinner and passed the time talking with my second partner and a few of his colleagues. The feedback step turned out to be very interesting and it's the only time during the whole event that I remembered why I had started this whole quest in the first place; to learn why Menlo was so successful at applying Agile. I started taking notes. They worked through each one of us, one at a time, randomly chosen. Each observer spent about one minute giving feedback. I was blown away as to how many people had hogged the pen and how many hadn't really been able to work together, let alone make their partners look good. I had been much luckier with my partners, than I had realized. On a personal level, I was very engaged when any one of my partners received feedback. Two were evaluated before me, so I received a lot of clues as to how I did through their evaluations. Obviously, when it was my turn I was all ears. I seemed to have done pretty well. I had one tough moment when being given my evaluation from the first observer. She observed something I didn't agree with. Even with a roomful of people, it was all I could do to not argue with her. After that, I kept a close eye on others for similar reactions. Not one single person argued with their observers although I could tell many times that they didn't agree and would have liked to. I imagine a few might have stayed behind for just that purpose. Resisting this urge in my opinion was absolutely the right choice, especially since this was a very tough thing for the Menlo team to do in such a public manner. All in all, the feedback step was done very well and the things I heard, including what the first observer said, will be useful to me in the future. Although a bit of a harrowing experience for me, I absolutely think this is the right way to interview. It takes into account some of the tenants of Structured Interviewing, reducing personal bias and insuring a sense of consistency. In addition, the idea of pairing gets to the heart of the Menlo culture, which is team work. Gosh, I really hope I get called back for the second interview... |
Mary and Tom Poppendieck in Ann Arbor
Mary and Tom Poppendieck were in Ann Arbor yesterday and I was lucky enough to be able to spend some time with them. Part of the day was an interactive event where teams used Value Stream Mapping to attempt to improve their processes. I’ve seen this exercise before at several other Mary Poppendieck events and yet it’s always a unique learning experience. What was surprising about yesterday is that all three of the presented value stream maps screamed out: ”Improve the Sales Qualification Process!”. What I liked best about the fact that all three really needed serious sales process improvement is that we were standing in the Joe Marr Sandler training center. Joe Marr and Mike Wynn weren’t around, but I think they would have loved it. So what did Lean say to do? What would Sandler say? First and foremost, Lean and Sandler both demand that you create artifacts as late in the process as possible or not at all. One of our biggest cases yesterday was a map that showed the company creating a proposal and a software demonstration before securing any real intent of purchase. After the proposal and the demonstration, then and only then was the customer asked to commit in any real way. The closing rate was less than 30%. There is no way Joe and Mike would have allowed that and of course Mary was having none of it either. Second, Lean and Sandler both say that moving closer to the customer and gaining a real understanding of their problem is essential to good closes that stay closed. Lean specifically says to break down those processes or habits that keep your implementation staff at arms length from the client. Sandler say “No Pain, No Sale”, which means you need to understand what the client really wants of course but it also means that you won’t keep the customer or get repeat business if you don’t solve the pain. Yesterday we saw a map that showed how the implementation staff only got involved with the client after the sale was supposedly closed and all the requirements were defined. The people who could have understood and solved the clients problems weren’t involved in the sales process, so instead, a lot of “defensive” process was added to insure that everything was defined in infinite detail and time buffers were added (both very un-Lean things to do). Still, with all of that, once the implementation staff finished what they thought they were suppose to do, they always had to make some changes, sometimes a lot of changes. I certainly felt I could hear the frustration in one of their managers’ voices when they described how the “Customers are picky and always have to make us change something”. Now obviously that kind of thing makes implementation difficult, but it’s not just implementation folks who suffer. The Sales manager probably spends an amazing amount of time fielding calls from frustrated clients or busily trying to find new clients because the old ones seem to disappear on a regular basis. In this case, I saw where moving programmers into the sales process could make a huge difference in both departments, saving time, money, and most importantly emotional energy better spent elsewhere. It really turns out that Lean and Sandler have a lot in common. I plan to annoy my wife by over analyzing this to death over the next few days. |
Agile Sales and Marketing
Agile practices lend themselves very well to Sales and Marketing, I use them quite a bit with my clients and I'm always discovering new ways that Agile can be applied in this space. Here's some examples of what I'm currently doing: The Daily Sales Scrum Having a daily Sales SCRUM is something that professional sales managers have been doing for years. They don't call it a SCRUM or a Standup, but it's the same idea. This works for the same reason it works for software development, by putting people together daily to discuss blocking issues, we prevent problems from festering for days or even weeks. Sharing experiences in a formal, standup format, makes a noticeable difference. In a small company, where there is possibly just one sales person who may not be doing sales full time, support is essential and a daily standup with other members of the management team can make all the difference in the world. As with a normal standup, have this meeting at the same time every day. Make sure everyone stays focused, because like a Standup, if this becomes an hour long meeting, it won't be sustainable. To keep people focused, try to have them only talk about what they are stuck on or need advice about. Victories and failures are good to share, but those really don't belong in a standup. Retrospective Many professional sales people take time to do this. Again they don't call it a Retrospective, but it's a similar idea. In sales we spend a lot of time inside our own heads trying to guess where we went wrong or what we did right. Formal Retrospectives are essential in order to stop guessing and start understanding. Working with others in your company, whether they are in sales or not, to document and debug critical sales experiences can be an extremely useful tool to breaking open new sales. Pair Cold Calling I know not all of you are making your cold calls and I'll address why you need to in another post, but for now, let me tell you how much more fun Cold Calling is when you're doing it with a friend. I started doing this almost 2 years ago and I can't tell you what a difference it makes. Like so many others, I have a love/hate relationship with Cold Calling. Pairing up with someone, not only makes Cold Calling bearable, it makes it downright fun. This is pretty simple. One of you makes the call why the other "observes" by listening in. If you are doing walk-ins (something I've done with a pair) one of you does all the talking while the other smiles politely at the prospect. After each call you swap, with the observer becoming the sales person and visa versa. When you first pair you'll start giving each other advice, but very quickly it will smooth out and the calls will just fly. I'm happy these days to do cold calls by myself, but if I had never paired, I'm not sure I would have ever come to accept cold calls as the necessary energizing event they are suppose to be. Test Driven Development Test driven development means to write the tests first. This helps you gain understanding of what you really want the code to do while giving you a repeatable test you can use from now until the 'spec' changes. In new sales we need to continuously reach good prospects. Reaching them means sending a message that they will respond to. I first define the prospect and the message and then I build the artifacts around them. In the example of a web page, I first design a set of goals in a very objective way using tools like Wordal and Google Analytics and then I build my site around those goals. In this way, I end up with re-usable tests that tells me if I got it right and if I continue to get it right. Those are just a few of many examples of how Agile can be a great fit for Sales and Marketing. |
Today is the first day of the rest of my blog
I'm going to start blogging through our new heitzeg.com site. Here we go... |
1-8 of 8