First Impressions of Apple Watch Workout App

I finally got my hands on an Apple Watch this weekend!  I've been waiting for this since it was announced, mostly for the promise of the workout features.  My 2+ year old MOTOACTV watch is finally starting to show it's age - although I still feel it's one of the best running watches on the market as it combines GPS, bluetooth, wi-fi syncing, and a color screen all in one.  Oddly, almost no other running watches offer that.

My first run with the Apple Watch was nothing short of a disaster.  Perhaps I have it misconfigured, but the three most common actions for me (starting/stopping at an intersection,  changing audio playback, and seeing my workout metrics) were all HUGE usability nightmares.  More coming soon, but suffice it to say that for a company that prides itself in design and has marketed this watch as a fitness device, my first impressions were very disappointing.  

Things I wish I could change in JIRA

I've now setup JIRA to be used in 3 different companies and have I ever learned a lot.  In general, I really like it, but I can see how others can share different opinions.  I do enjoy how Atlasssian has been making some great improvements lately, especially around the "Project Overviews" and Git integrations.  They generally do a great job of walking a really fine line between being completely customizable (and utterly confusing, umm, I'm looking at you IBM Rational Team Concert) and being overly simplistic (Asana? Trello?).  With that said, there are a complaints that I find myself using ugly work arounds for or unfortunately just having to live with:

1. Email Notifications!  JIRA sure is good at sending out emails (or NOT).  Want to make one tiny little change to a non-critical field on an issue?  Sure, but that means the 6 other team members following that issue will all get an email.  Make a typo in that first update and want to fix it 10 seconds later?  That's okay, JIRA will send YET ANOTHER EMAIL.  Why not try something like this:

• Allow each user to tailor their own email preferences, instead of it being globally set
• Change the content in some email template to better allow users to setup their own inbox filters so they can see the emails they need to see and allow themselves to systematically exclude themselves from emails they don't.  Github does a good job here - I'm added in the "to" field if I'm tagged in a comment, but other emails I get (such as a new Pull Request that I'm not a reviewer) I'm BCC'd
• Just as users can decide to send an email or IM, let them decide whether or not the particular change they are making should or should not send an email.  Oddly, Atlasssian does this quite well in Confluence, just not JIRA
• Bundle up changes made within a few seconds of each other into just one email

2.  Backlog management.  I've tried a million strategies but everything always ends up with ugly work arounds that nobody else understands or can reasonably be expected to maintain.  There must be a better way to manage a product backlog.  The "Plan View" of sprint boards comes close, but what if you want to use a Kanban Board instead?  My current approach is to bastardize the use of "Sprints" in order to be able to find/plan/communicate what work is in progress, up next, or at the top of the backlog.  This is confusing, especially because in doing "planning" I inevitably end up sending a bunch of system generated emails out to users as I make changes, then reassess and update them a 2nd time.  

3. Searching for Children.  In the On-Demand version which doesn't allow plugins, it's impossible to find child items of an Epic based on particular attributes of that Epic (such as Status or Label).  I always find myself wanting to write queries that include searches like this, especially for Epics that cross multiple projects (such as a feature being added to both an Android and iOS app).

Building Respect in a New Team

Starting in a new team, especially when leading a team of smart engineers, is always a delicate dance.  Learning a new company, forming new friendships, understanding a new application, and likely learning new technologies all at once, what could go wrong?  That first small win where your team begins to trust and respect you is always so rewarding.

This essay does such a great job summarizing the feelings many of us have had:

You start climbing out of The Great (Incorrect) Disappointment with a small unexpected win. No one expected you to fix that, no one knew it was that broken, and no one thought it was that important. When you fixed it, no one really noticed. When the consequences of the fix became obvious, they thought, “He can do that?” Your fix is your first legitimate reputation defining moment because while people were told who you were, they didn’t believe it because people don’t believe what they have not seen. The Great (Incorrect) Disappointment vanishes slowly and quietly each of these smalls wins. The wins don’t feel substantively nor impactful, but they continue to incrementally define who you are to the rest of the team. They start to build a realistic model of you in their minds. You’re not who they expected, it’s not what you expected, but after three months you start to think of this strange place as home.

Leading a Team as a PM

I love building software and seeing as I've thus far decided to be a generalist in my career that has usually meant that I'm a PM for a team of specialists.  Managing projects should never really be easy; if you find yourself coasting that likely means you are being far too conservative.  If you are struggling, Robbie Abed recently published a great essay on Project Management that hit upon many of the same things I've learned thus far in my career, especially the two philosophies he lives by as a PM:

1. My #1 job is to make everyone's life around me easier.
2. My #2 job is to make everyone else around me look good.

I could not agree more with these philosophies, especially #1.  I believe in being fully transparent with my teams, but at the same time I strive to do whatever is possible to let those in my team avoid the distractions and focus on the work they are best at.  I shield them, baby them, spoil them.  Need help with writing that script?  Sure, send it my way.  Need me to waste an hour debugging some slow running query?  Here you go, this join is causing us some problems.  Need a quick wireframe for that page?  Just give me a few minutes.  It's one way for me to not drift too far from the details of the project, but it also earns a lot of respect from those I work with who can focus on other stuff that only they can deliver.

I can also think of a few people I've worked with that at first I didn't really see eye to eye with.  Robbie writes:

There is no such thing as a difficult person on a project. It's just someone who you don't understand why they act the way they do. Understand their motives. Understand why they are being difficult. Understand how you can make their lives easier. Understand what makes them happy. Ask how you can help them. If you make their life easier, you will become best friends with them and they will give you everything you need in a timely fashion.

On a personal level, I naturally enjoy making people happy.  As a PM, I enjoy my team being as effective as possible.  Usually these go hand in hand.  Finding what motivates someone can take a little time, but it is totally worth the effort.  One team member always enjoyed the free food I'd bring back from the common area, another liked the detailed specs I'd write, many appreciated the hours I'd spend answering questions even though they knew I was super busy.  Empathy and compassion will go a long way towards earning the respect of one's team and more often than not delivering solid products.