How to be Perceived as Being Credible

In The First 90 Days, Michael Watkins writes about new leaders making transitions. He says they’re perceived as more credible when they display these characteristics:

  • Demanding but able to be satisfied
  • Accessible but not too familiar
  • Decisive but judicious
  • Focused but flexible
  • Active without causing commotion
  • Willing to make tough calls but humane

Since perceptions are weighted so heavily in people’s minds it’s important to make a good one in a new job or new role. Make this your priority in every initial transition.

Release Early and Often

Tempting as it may be to sit on your new code, working to improve and make it the best it can be, it’s the wrong thing to do.

We’ve all been there: the new project is cool; it looks great and customers will love it, but it’s not quite ready. Just a few more things to make it look really great.

If you’ve ever had to decide the best time to start having kids you already know there’s never a great time. You’re never fully prepared, your finances aren’t in order, but you do it anyway.

Cod is the same way. Release your Minimum Viable Product as quickly as possible and schedule time to iterate as quickly as possible. The added benefit is a shortening of the feedback loop. You might decide not to spend days building and perfecting something you thought would be great when users tell you they don’t actually want it.

Release your code early and often. You’ll never feel ready but that’s the point.

The Pros and Cons of Creating Sprint Goals

Roman Pichler has great insight on most things Agile related, but especially to creating sprint goals.

I had never looked at it through this lens before. Goals had always been more of an afterthought.

Pros for creating sprint goals:
  • A dev team is united towards accomplishing one thing through many stories
  • Stakeholder communication – instead of trying to understand individual, unrelated stories, they only have to understand the work that’s being done to affect a single goal
  • In Sprint review we mainly measure the work against a single goal
  • Helps prioritize; on a Friday afternoon I can get the stakeholders to agree to a single goal and then figure out the work that fits into the sprint (and not have to show a full Jira backlog to get there)
  • Teamwork; since we’re all working to accomplish the same goal and not unrelated stories (account speed as a goal could still contain stories for emails/video loading AND a story for lists though)
  • We usually have a number of small things that find their way into each sprint, unrelated to the whole (like bugs)
  • Hard to put a full team on one goal, perhaps the fix being to create smaller teams