Day 2

Yesterday was the first day on the new job. Today was the reason for starting on Thursday - Leaders Strategic Meeting.

This meeting kicked off with the CEO's intro, a financial overview, review of new corporate mission and vision, operations review, product management market view report out and finally Q&A. This was a great way to spend the second day on the job. I got the corporate overview all in one shot.

So at the end of the first two days what have I learned:

• Assimilation is a process like any other and it has its own timeline. Being energetic is great, but temper this with the understanding that the new job is an endurance event. You don't want to burn out too soon or be perceived as trying to change too much.
• Smile and try to place a face with a name and function. Everyone and their roles are new to you. The faster you learn who to turn to for specific functions the sooner you will be on your way to effectiveness.
• Before rushing to what worked at the 'old' find out the history at the 'new'. You were hired for the potential skills you bring, the current team has been employed because of the skills they have displayed. During your discovery phase you may find that what didn't work for your past positions works well at your current position. (or vice-versa) Modulating your suggestions will ensure your credibility grows with each day.
• The theories and material I have been reading to increase my personal knowledge with is great. Now is the time to put it into practice. Reality has a way of being different than a case study.
  

What's next?

• Understanding the product portfolio - how does my product line relate to the other products produced
• Understanding the sales channel - who are the company's direct customers, who are the products end users, are the the same, if not what methods are used to get product into the end customers possession
• Understanding the product market place and any influences that may be present
• Finally, understanding management's expectation for me and my role, how will these expectations be measured, and what are the most pressing two or three priorities.

What other suggestions do you have for a new hire?

New Beginning

Today was the first day on the job for me in quite some time. The economy has not been so friendly to me (and a few million others). It was nice to finally come in out of the cold. The new company is really excited to have me and vice-versa. I thought this would be a good time to resurrect a defunct blog since I will have ample substance to post about now.

Today’s topic - That First Day

My last “first day” was 10 years ago. I had forgotten the assimilation process. Today it all occurred at a dizzying pace.

8:30 AM	Meet my new manager
9:00 AM	Hand off to HR for corporate assimilation. Review policies and benefits and fill out necessary paper work (homework)
10:00 AM	Engineering meeting I
11:00 AM	Engineering meeting II
12:00 PM	Meet up with manager and CEO for corporate overview & lunch
1:30 PM	Product management team meeting
3:00 PM	IT review of phone and computer setup

With the assimilation complete now what? I find myself facing a triple learning curve with this new position:

• New company and their processes
• New product domain
• Finally a new product form (HW - new vs. SW - old).

The big question is what to start on first? I am going after the new product domain.

What would you do or what have you done if you have recently found yourself in a similar position?

Hockey Sticks & Flywheels

Yesterday's post regarding a split life, I feel, cleared the way to talk freely about all aspects of my life. It represents the knee in my personal hockey stick. What? You know the inflection point where it takes off up and to the right. A past boss described my performance that way. He wasn't sure for the first couple months about his hiring decision and then he just watched the progress unfold.

The past few months have been spent churning things around internally about an online presence. While at the same time I have been following people; 140+ on Twitter and 30+ blogs. This has given me an decent lay of the land in Web2.0 space and created a good foundation or base from which to speak from. During this time an outsider would have seen little of significance from me. This being the blade of the stick; nearly horizontal with some slight positive slope.

Concentrating on the foundation develops a stable platform to launch everything else from. I have personally experienced this from iron distance racing. Iron-distance athlete, Jim Collins uses a similar example of a flywheel in his book "Good to Great."

"Then at some point - breakthrough! The momentum of the thing kicks in in your favor, hurling the flywheel forward, turn after turn...whoosh! its own heavy weight working for you!

Being a closet triathlete artificially limited the amount that I felt I could say. Jim Collins points out that "good-to-great transformations never happen in one fell swoop." Acknowledging all dimensions of my life enables me to more efficiently spin the flywheel. I still see work in front of me. I also don't think that if I had a posted this four months ago the other work could have been ignored. The base is still needed.

Each year the base needs to be rebuilt. This is true in either triathlon or business. December is the end of the year and the typical time for reflection. It also offers the opportunity to look forward to the New Year and the changes that are necessary.

How big is your base? What would it take to knock you off balance? What are you going to do differently in the upcoming year to improve?

Convergence

Do you lead dual lives? Work vs. Personal? Public vs. Private? Do you find common themes between the two? This post is about all that and bringing both worlds into the same light. (Oh no, worlds colliding...)

I am a closet triathlete. Not your typical person that enters a race here or there to celebrate a life milestone, but what some would call crazy. I have been doing an Ironman a year for the past 10 years. During this time, I have downplayed what many consider a tremendous achievement. Why? Because there tends to be a stigma associated with someone that exercises to that degree. People are skeptical about how I can manage that and a full time job. When I tell them it is easy I can see their faces fall. That is not what they want to hear. Don't get me wrong, doing an Ironman takes commitment and discipline. I will be the first to admit it is not for everyone.

When I say "it is easy" I am referring to mastering the basics. Most people have done it, they just don't realize it or don't like doing it. Daily everyone prioritizes things and makes sacrifices for the higher priority items. Exercising and being able to cover 140.6 miles in a day is higher on my priority scale than watching a football game or an evening sitcom.

That is some of my personal life. On the professional side, I am an engineer most recently working as software product manager / marketing person. I enjoy it because there are continual challenges. Priorities are constantly shifting. You have to be thinking ahead to make it all work within the allotted time. You are constantly working towards milestones or release dates. If you are not, then you are critiquing the product, evaluating its performance through the customers eyes and planning the next improvements among other things.

Notice how professional life mirrors personal life? I do not sign up for an Ironman race one week and show up to race the following. There is planning and challenges to overcome. One of the first one's is to even get into one of these events. Believe it or not, they sell out in hours. Once you are successful at getting into the race then you have to plan your time. There are macro cycles and micro cycles to be considered. As part of the "training plan" various milestones are incorporated such as a half marathon or a 100 mile bike ride. These enable you to checkpoint your progress. Am I on track to do the full Ironman race or does one sport need improvement. What goal times were set for these milestone events. This is my "customer" feedback. I may not like what the clock says when I cross the finish line but it is very real and undeniable feedback.

Crossing the finish line after an Ironman race is an indescribable feeling. A mixture emotions flood through your weary body and mind; elation at having completed the race within the allotted time; either joy or sorrow depending on race result; there is also some disappointment because that is it. You are truly finished. Some Iron-athletes talk about a post race funk because they feel they no longer have a purpose to train.

One other benefit is the knowledge that I was able to set a large goal and achieve it. Over time I have found that this is my main reason for doing these races. The self confidence to face most any challenge is very empowering. For example, 24 hours before the expo and the new product demonstration just fell apart - no problem, there is plenty of time.

Prior to this post, I tried to maintain some separation between the private and professional worlds. Having gotten back into some low level training I have had time to reflect on that and how it was not truly healthy. They balance each other out nicely and enable a high level of performance across both. I can feel a writer's block being unplugged and look forward to combining the experiences going forward.

Back to the original question: Do you lead a dual life? Are there common elements in both that support the whole person? Why do you continue to keep them separate?

Blogging Renewed

Today I read Andrew Sullivan's article "Why I Blog" from November 2008 Atlantic. Andrew draws a comparison to jazz explaining the difference between formal writing and blogging:

To use an obvious analogy, jazz entered our civilization much later than composed, formal music. But it hasn’t replaced it; and no jazz musician would ever claim that it could. Jazz merely demands a different way of playing and listening, just as blogging requires a different mode of writing and reading. Jazz and blogging are intimate, improvisational, and individual—but also inherently collective. And the audience talks over both.

It was with these thoughts loose in my brain that I went for a morning run. Exercise, for me, always breaks the thought jam and results in creative ideas. The end result was a new found perspective on blogging and several topics that wanted to come out. Rather than being worried about correctness and credibility I felt compelled to just get them out. (at least this one is a start)

Of course this is a familiar path that I have said to myself more than twice over the past month. One time was after reading Taylor Graves' post titled "Risk: What is the value?" One quote from the article was "You don’t become an innovator by playing it safe." That was like looking in the mirror. I had never been risk adverse but in the blogosphere I am finding that I wasn't too anxious to post an opinion without checking the sources and verifying my correctness. After reading Andrew's article the reality is that the blog is more or less spontaneous. That is part of the beauty of blogs and developing the conversation. Procrastinating has caused many topics to fall by the wayside. This has also led to me straying from my original intent with the blog to join the conversation.

How do you manage to generate interesting content and keep the conversation going? Do you worry that a post is interesting or not?

Combating Rogue Development

Following on from the previous post - The Cranky Product Manager's Imposition: WTF Refactoring?

Scene: War Room. 2 days until Code Freeze.

LEAD DEVELOPER:
So, unfortunately, we’re going to have to pull FavoriteFeature out of the release in order to meet the schedule.

THE CRANKY PRODUCT MANAGER:
Huh? That feature’s been in the product for 3 releases now. Customers love it. Why do we have to pull it?

LEAD DEVELOPER:
Well, we had to refactor the code, but unfortunately we just don’t have the time to write unit tests.

Fast forwarding...

LEAD DEVELOPER:
Well, I, uh…. Well, …while the guys were in there modifying, you know, the CODE, well, they, uh, figured they could, uh…, well…, add some stuff to create some WICKED cool Hologram broadcasting stuff. It affected the old tests.

THE CRANKY PRODUCT MANAGER:
(pause)
First, Hologram what? That’s not in the backlog!

LEAD DEVELOPER:
We thought it would be cool.

This is a situation or something similar that happens too often. Engineering wants to do something "cool" and may at best slip the release date. At worst, as in this example, product quality and features may be compromised. What is a Product Manager to do? The development effort happens at too many levels and areas to keep track of and still performing all the other Product Management functions. So what can be done about this?

Several things, the choice of which depends on your development atmosphere and program maturity.

One of the buzzwords gaining traction since 2001 is "Agile Development." Agile development encourages frequent inspection and adaptation. It is a leadership philosophy that encourages team work, self-organization and accountability. The weekly team meetings may have revealed that the "unit tests" were failing well in advance of code freeze. There is also less of a reliance on a true code freeze. Features are implemented in small bite size and scoped chunks over iterations. These iterations last from one to four weeks. Because of the frequency of these iterations the code / product has less of a chance of deviating too far from the code's projected path. It also has the ability to change direction and focus as the market needs evolve.

Agile development emphasizes people and interactions over tools. The original incarnation was to use sticky notes on a white board or wall. With time, tools became an inevitable out growth. They do help automate and manage the process. Also, sticky notes do not work for remote teams. Free tools such as Agilefant and XPlanner can be used from the open source community. (http://www.agile-tools.net/) If you have the budget, subscription based services can be had from Rally Software or VersionOne. There is a whole ecosystem building up to support this development need so I won't belabor the point.

Agile development can be a bit of shift in thinking for some development teams. Another approach is to modify the code check in process and have the development team itself monitor what is being produced. One model that I have seen used with good success is a two tiered code submission process.

Individuals work in their own private "sandbox." When the feature they are working on is complete they check that in to a sub-system location. A sub-system integrator (SSI) takes the code that was checked in and builds it as a unit. Regression tests can be run on that unit before it is checked into the main code base or 'head'. The whole purpose of this exercise is to ensure that the main code line remains stable. Members of a subsystem team can be rotated through the SSI role. This way everyone gets the responsibility for ensuring sub-system's stability and no one is ever always the policeman.

With code in various stages of development, acceptance and testing it may sound like a management nightmare. It does not have to be though. Establishing a holistic approach to software development can smooth out potential problems and keep everyone informed as to the release's status. Treating the process of specification, development, testing and deployment as a continuously repeating cycle frees teams up to focus on what goes into the software rather than how to get the software out. This is referred to as Application Lifecycle Management (ALM). Now instead of treating each piece as a separate entity if you can tie them together the entire team is aware of where the code is in the development cycle and what is in the product.

Referring to the CPM's example from above and using a rudimentary example to finish the story out; a specification is created with some identifier. This is agreed upon with engineering and work begins. The code, when ready for testing, is checked into the release branch using the earlier assigned ID. A flag is set to indicate the ID's status as "checked in." This can be seen by the various team members (i.e. Prod. Mgr., QA, docs, etc.) The other members can then begin taking care of their part of the development process. As they complete their functions associated flags are also set until finally the feature is deemed complete. Repeating this process for all the features assigned to a release finally culminates in the release with known entities. No last minute surprises should occur.

Of course, this is all in a perfect world and everything works flawlessly. I have also managed to shorten book length topics to a single paragraph or two. I would be interested in how you have managed to reign in rogue development work? And what was the effect on the team's creativity? Let me know.

Jumbled Thoughts

Today's entry is about writer's block. We all get it. Sometimes because we don't have anything to say. My problem lately is I have to much to say but it all cannot come out in a coherent manner. So like 2 large individuals trying to pass through a doorway at the same time it gets stuck.

Combating this situation today I went for a bike ride at lunch. After 25 miles things started to break free and by mile 30 I was starting to get the makings for a decent commentary.

The break through in my log jam came by thinking about two posts nearly simultaneously. Brad Feld's "Running and My Professional self" and Taylor Graves "Layoffs." What do they have in common? Nothing until they wind up in my consciousness.

Here I was exercising while during a stint of unemployment. I was trusting that clarity would come as it has so often in the past. The past few months I have been not allowing myself the usual lunch time ride. My thoughts were that this was a guilty pleasure that I couldn't afford. Today I took it because it was obvious that nothing was happening on my end this morning. My hope was that the fresh air would clear my head like Brad's runs. The fact that it took so long showed how out of practice I was at clearing my head.

Taylor's post was good because it struck a cord that someone still so early in her career could have a positive and mature outlook on her situation. I am not sure I could have been so positive 10 years ago. Today, after several months of fruitless searching I am still relatively up beat and optimistic despite everything that the economy seems to be throwing at me. While I found her post refreshing, it tended to put some pressure on me to get my act together. Then, in that Aha moment I had remembered, I got my inspiration.

My mind turned to yet another blog post by the Cranky Product Manager. She was ranting about code refactoring and product features.

Having been in her situation, I can sympathize with her. Witnessing the impact on the product quality and team moral I applaud her upfront method of calling BS. What now? Well, the tactical implications are the lead is probably going to be pulling a few all nighters or the schedule may slip. It depends on how hard line she gets. My guess is that they schedule will slip over her dead body. (I cannot wait to read about the carnage)

This may or may not be the first time this has occurred on her team. It sounds like a seed of doubt has been planted and future excuses are going to be easily dismissed. Are there things that can be done to restore happiness in development land?

Let me know your thoughts.

I meanwhile will share mine in tomorrow's post since that bike ride was so good at getting things sorted in my head.