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.

Becoming A Software Strategist.pdf

I’m a software manager, now what?

In the field of software engineering, leadership is still far behind the capabilities of those that design, create, test, deploy and support software offerings.  This won’t come as a surprise to those who have been in the field for more than a few years.  The reasons for this are varied, but in my opinion, the number one reason is the Peter Principle:  “Employees tend to rise to their level of incompetence”.  

The Peter Principle first appeared in the 1969 book by the same name.  The idea behind the Peter Principle is that people will be promoted based on merit and then find themselves in a job they aren’t capable of doing.  This seems somewhat obvious, but it’s not always easy to recognize.  When we see someone move from a technical position to a management position, it’s very easy for them to end up out of their depth.  

When I say a management position, I’m speaking of something very specific.  This is someone who has direct technical reports and/or is responsible for delivering a complete software offering.  

A software developer who becomes a manager has been put in a whole different world than they have been used to.  Their comfort zone is almost completely stripped away.  We see many reactions to this, but the most common is that the manager stays in the software and focuses their time on micromanaging the codebase.  This can have disastrous effects on the team and the software being delivered.  

There are two key practices that I have found very helpful when making the leap into management.  First, replace yourself.  Second, spend as much time learning to become a manager as you spent learning to become a software developer.  

Replace yourself

If, like many other managers, you were promoted to head up a team you were already a part of, then you need to replace yourself.  In most cases, this is going to be incredibly hard to do.  You were most likely already a lead developer and were the “goto” person for many of the harder issues your team was facing.  In fact, your boss might have said something to you like “Hey, I want to promote you to manage the team, but I still want you to write code”.  If you fall for this, it’s going to be the first step to a very unhappy management experience.  Remember you’re a manager if you have direct reports and/or are responsible for delivering a complete software offering.  You need to step out of your comfort zone and focus on your primary responsibility, which is management.  You can’t do this if you’re the “goto” person on your team.  Even more so, if you want your team to grow and become better, you need to build more goto people onto the team.  This is a great exercise for a first time manager.  It allows you to start making your team stronger, while at the same time freeing yourself up for your new job.

Learning

Spend as much time learning to become a manager as you spent learning to become a software developer.  Managing well is incredibly hard to do.  Think of those managers you’ve worked for that you:  “Love”, “Hated”,  “Felt Sorry for”, “Disliked”, “Enjoyed”, “trusted”, “distrusted”, etc.  Each one of them were doing things that caused you to form opinions about them.  Articles, books, podcasts, training courses, seminars are at least as prevalent in the field of management as they are in the field of software.  As with software education, you have to look for the right ways to learn and practice your new craft. The important point though is that you didn’t become a great software developer in a vacuum, you won’t become a great manager without the same kind of continuing education.

Three books to help out a new manager

Growing Great Employees - Erika Anderson
An excellent, easy to read book on how to grow your current team and how to hire new team members.
Crucial Confrontations - Kerry Patterson
A must have book for learning how to work with your employees, your peers and your boss.

Financial Intelligence - John Case
If you, like me, don’t have any formal financial training, this is a great book to help get you up to speed.

Mike Lambert on using UUID as a primary key

Mike Lambert wrote an excellent article on using UUIDs as primary keys in a database.  This is definitely worth a read even if you don't need this right now.  The approach is elegant and the article is a fun read.  This is on digitilapia.com

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

Our Bernard Gadget

If you are a google gadget user, you can try out my simple gadget by adding the following to your google page:  http://bernardpreserve.googlecode.com/svn/bernardpreservegooglegadgets/BernardPreserveGadget.xml

This is all brought to you by the Bernard Preserve.  A way of collecting the very best of therapeutic drool available south of mackinaw.

We moved the Bernard Preserve Site

We moved the bernard preserve site to bernardpreserve.org. Just in case you're keeping up. Thanks for watching. Here's a picture of Bubba, whome I still love even though he left me and never calls or writes:

I've reinstalled Eclipse like 5 times in the last 6 months. It's not an Eclipse issue, it's just that I keep trying different operating systems and different machines (fun but makes life a little crazy).

Anyway, for some reason I can never remember how to turn on line numbering in Eclipse.

To turn on line numbering in Eclipse:

• Windows | Preferences
• General | Editors | Text Editors
• click the “Show Line Numbers”

Eclipse and JEE with Bill Heitzeg

Even though I was the leader last night, I learned quite a few things. First apparently when you're logged into google it returns "your" top searches, not necessarily "The" top searches. Thanks to Jay Harris for that.

I tried last night to mix lecture and the practical. We worked through the foundations of JEE (the Servlet and the jsp page) using Eclipse. It was very hard to do in an hour, but from the feedback I got, everyone seemed like they learned something they didn't already know. As Jay Harris said "Sometime's clicking on New Project for the first time is the hardest part of coding". He was full of sage wisdom last night.

Next week Chris Marinos is leading on F#. Tonight Chris is speaking on F# at Ann Arbor Dot Net Developers. Don't miss it.