Jonathan's Blog
name

Jonathan's Blog

Mindful Leadership and Technology


Featured

AI Technology Leadership

AI Resources - TensorFlow

Posted on .

I mentioned in an earlier post some free Amazon resources that are available for managing AI projects - I think those are really valuable and they are still available here:

ML for Business

These are really good for getting an overview of what a typical machine learning project looks like.

If you are interested in going a little more in depth and seeing the guts of what machine learning looks like it is worth taking a look at the TensorFlow tutorials:

TensorFlow Tutorials

There are five links on the bottom of the page that will take you to 5 different tutorials, I'm currently on the third, but it is very educational.

In one sense, these aren't for the faint of heart. They are really doing real machine learning, and if you're like me, you won't understand some of it. That's OK.

You need to look past a few things you don't know and just plow ahead they really do give you a great idea of how machine learning actually works.

Unlike the Amazon courses, which don't really require any prerequisites, you probably need some experience with development tools to get through the TensorFlow tutorials. They require that you are comfortable clicking a Play button like you run across in development environments, and sometimes you are kicked back warning messages that you have to look at, stomach, and promptly ignore.

While I've tweaked a couple of print statements to get the notebooks to show me different stuff, I'm really not messing with the core of what the notebooks do. I can generally make sense of it, but I don't have the skill to change the core logic of what these are doing.

I actually very much appreciate the concept of the notebook - it forces documentation into your work in a much more direct kind of way than traditional programming where comments and documentation are often an afterthought. Every example I've come across has had lots of helpful information (they are tutorials) and the text that is presented alongside the code is indispensable.

If you want to know more about machine learning, and you aren't afraid to see how the sausage gets made, it is worth checking it out. Highly educational.

Featured

Leadership Software Development Agile

Software Product Owner - Do I Need One?

Posted on .

The most effective Product Owner I have ever worked with did not have that title. I mention this at the outset of the post merely to say that titles don't really matter that much. What matters is the role itself and organizational empowerment to do the job right.

You have a Product Owner because you want to go fast and develop great software. If you don't have one you are making the choice to go slow, which is always a bad idea. You may develop great software anyway, but it will take longer than it needs to.

The product owner is a critical role in modern software development. The Product Owner’s role is to supply the following to the development team:

  • Product Vision
  • Release Vision
  • Feature Backlog
  • Prioritization
  • Decision Making

Effective Product Owners work with stakeholders (usually customers, executives, business decision makers, and visionaries) to supply an effective workstream for their projects. Very often good Product Owners are neither the visionary nor an executive, but are someone with the ability to manage those people and the guts to make decisions about the product.

Ineffective product owners are too busy doing other things to be bothered with the day-to-day decision making of the team and leave questions unanswered for long periods of time, delaying the work.

Effective product owners manage and participate effectively in two work cycles:

  • The Development Sprint Cycle (usually 2–3 weeks) A good Product Owner makes time to attend important meetings and answer questions for the team doing the work.
  • The Product Development Backlog Cycle – A good product owner is constantly working with business stakeholders and customers (end-user customers) to understand what is working and what isn’t.

Ineffective Product Owners don’t spend the time necessary to get their product backlog prepared. This leaves their teams unable to plan or estimate work – delaying progress, de-motivating their teams, and creating blind spots in cost and timeline for their projects.

Effective product owners work hard to understand their competitors and customers, they know their place in the industry and where they are trying to go. Being an effective Product Owner is typically a full-time position, I seldom sees a product owner that can handle owning more than 1 product, and I have never seen one able to effectively handle more than 3.

Featured

Agile Software Development Agile Leadership

Decision Making and the Role of the Product Owner

Posted on .

I just completed my Scrum Certified Product Owner training and certification class here in Boulder. It was a really excellent class taught by scrum guru Mike Cohn.

I learned a lot about how to do the expectations for the role of product ownership, and lots of techniques and processes for how to do the job effectively. The class was very engaging with a good mix of instructor-led content and group activities.

One of the most significant aspects of being a Product Owner in scrum is making decisions and prioritizing work.

Here are some things that will make it difficult to do the job effectively:

  1. You aren't given the authority by your organization to make decisions for the product.
  2. You don't give yourself the authority to make those decisions.
  3. You have a hard time making any decisions.

Number 1 on the list is something that you can do something about, and we spent time in the class discussing it.

If you are undercut by superiors or colleagues, you need to address that with the superiors and colleagues. Often times they may not be aware of it, in which case simply brining it up is enough to make a difference.

In other situations you may need to understand the why of the situation and seek to improve your understanding of the business or your boss vision. Then when you are on the same page you will have less conflict and less decisions that have to be revisited.

If the your boss, colleagues, or team leadership fundamentally doesn't trust you or anyone to make those decisions - seek alternative employment.


But what about 2 and 3? I wrote a recent post about absence of emotion in decision making.

Similar things apply here. If you believe that you can be an effective product owner and make the necessary decisions based solely on data, abstract principles, and rational thinking, you will run into problems. You will never have enough data to make all the decisions you have to make NOW.

You can have the data in 3 months, but the world may have passed you by then.

An effective Product Owner is going to Know a Lot - they will know the domain, they will know the analytics, they will know the users (some of them personally). They will use all of these things to make decisions.

But they won't (and can't) know everything. Even if you could know everything today, you wouldn't know everything tomorrow.

And when you don't know everything, you will have to make decisions in the absence of data. In these situations, you need to know your instincts and trust your insight to guide you.

And trusting your gut means listening to and understanding emotions - and being able to defend that decision. Whether you call it trusting your gut or rapid cognition you will need some of it to be an effective product owner.


If you aren't used to working this way, then you can choose to focus on the activities that will make your insights and intuitions more informed - learn things, focus on data, know as much as you possibly can.

Then when you need to make a judgement call, you will have a solid foundation that you have built upon to get there.

But when the time comes, you will need to decide in the absence of data, and you may have to argue your point, so be ready to put some feeling into the discussion and push for what you think is the right answer.


When you find yourself in such a situation, the best and easiest way to handle this is to recognize that this is the situation are in: You don't have enough data, you will need to make a recommendation and push for what you think is right.

I find that simply acknowledging the situation as such - whether externally, internally, or both - is very helpful.

It is also helpful to remember in these situations that most bosses want someone who will make a strong recommendation and push for what they think is the right answer.

They will see you as providing decisive leadership and be able to back you up in your recommendation, without needing to get deeply involved in the data, details, or weeds. You are smart and well-informed, it's your decision to make as the product owner.

If you run into headwinds here then the same recommendation applies as above: seek to understand those headwinds, adjust if necessary, continue making recommendations based on the best data available.


You may be wrong.

We're all wrong sometimes.

Being wrong is an opportunity for further introspection and learning. Accept it as such, make further adjustments and move on.

Featured

Leadership Mindfulness

Managing Change - When Adaptability Becomes Liability

Posted on .

I've written in the past about the emotional rollercoaster and how you should think about it for the purposes of productivity and team building.

I got this basic picture from Dr. Alan Watkins in his book Coherence. It is based on the emotional range that we experience during any change, based originally on the stages of grief. For the record, the negative emotions laid out by Dr. Watkins are:

Denial (at the top left)
Resistance
Anxiety
Frustration
Despair (at the bottom)

Yikes. Yes, those are the negative emotions we experience during change.

My original article is here.

Another way that this impacts organizations is that leaders often become extremely adept at handling these emotions in themselves, and this presents two risks:


The first risk is that the leader can be in a very different place on this roller coaster than where there fellow employees are. Leaders often get advance notice and have more time to process. They also may have more experience dealing with change all across their organization.

Employees with less flux in their day-to-day duties may not be used to riding this roller coaster, and so the leader struggles not only to understand why someone isn't already on the right hand side, going up, they miss that the struggle is there at all.

The key tool to avoiding this pitfall is awareness. Are there big changes going on? Expect that everyone is somewhere on this continuum. Talk about it. Ask questions, don't accept "I'm fine" as an answer. People may be coping, people may be struggling, people may actually be fine.

But as a leader you need to know for sure and it may be that someone who is really on the right hand side has some insights that could benefit you or someone else. For this reason alone, don't accept "fine", even if they're fine.


The second challenge is that leaders can believe that they are so good at this that it doesn't apply to them. They may believe that they don't feel the negative emotions or that they know how to speed through the emotions on the left quickly. They probably can do this for small or medium sized changes.

Leaders often thrive on change - this is certainly the mold that our culture has laid out for us.

But what happens when the change is large, unexpected, or drastic? What happens if you aren't used to processing the negative, left-side emotions? What happens if you've become so accepting of the leadership norms of change that the negative emotions are unfamiliar territory.

Today's norms say you can't be afraid, desperate, or angry about change. You can't be anxious, frustrated, or in denial. You certainly can't feel despair. You need to understand and move to acceptance quickly. How else will we lead others effectively?

But things happen. Some times a change seems personal. Some times a change is personal. Sometimes a change originates in the personal sphere and comes crashing into the professional. Sometimes we end up on the left half of this roller coaster, going down, and we don't have the ability to simply fast forward through it.

When this happens we need to accept in ourselves that there is a probably a reason and look for it. It may be that a trusted friend can help, it may be something that you do on your own.

If you are stuck (just as employees, peers, and bosses often get stuck) this is not wrong. This is something that can help you go higher and achieve more when you understand it, work through it, and get yourself on the right hand side, going up.

What's most important is to not let your normal adaptability and capability force you into believing you're somewhere you're not. Leaders ignore their own emotions on the left-hand side at their own peril. You're likely to come off inauthentic and fail to help others on their own journeys if you automatically skip ahead to the right.

This lack of self-awareness can lead to lashing out or feeling disconnected. If you are angry or disconnected people will assume even more negative things about the change. At best this means they will think you are an inauthentic jerk. At worst this means that they'll think you're hiding something, which, in a way, you are.

They will make their own guesses about what you're hiding. Usually what they assume or gossip about will be worse than your own struggles with a big change.

Featured

Leadership Machine Learning AI

Free AI/ML Education from Amazon Focused on Business Decision Makers

Posted on .

Amazon has recently opened up some of its internal AI education resources for anyone who wants to use them.  They're freely available on its learning platform, which you can use if you have an Amazon account.  

I'm currently working through the Machine Learning for Business Challenges course, which has some great content.  It's available here:

ML for Business Challenges

It's great if you ever wanted education on:

  1. The basics of ML explained in a non-technical way with lots of useful examples
  2. What kinds of problems are good for ML and which aren't
  3. What kinds of questions to ask to make sure your team is thinking about an ML problem the right way
  4. How to define the scope of a ML solution

The lessons are succinct and digestible, with lots of demystification and straightforward examples that show you how machine learning can benefit you, and when it probably isn't the right solution.

Here is a link to all the business decision maker classes:

Machine Learning: Business Decision Maker

Featured

Technical Value is Business Value

Posted on .

When software developers are focused on good design - focused on taking the time to build a system the right way - they are focused on delivering business value for their customers or stakeholders.

They want good design because they know that in the medium and long term a system with good design is easier to support and extend. This has clear business value - you can do more new stuff (features) for less money and you can fix problems (bugs) for less money.

More stuff for less money is good business value. In this way technical value (good design and elegant coding) is business value.

A system with poor design may get more features built more quickly, but before long the productivity will break down as the absence of plan results in fragmentation and chaos.

So in this way, you may get a quick hit of productivity, but in the long term you spend much more to get less which is bad.

There are times in every project where you reach an inflection point and what I described above needs to invert, temporarily. See this earlier article on the topic of technical debt and why sometimes the two can be at odds.

During the inversion, you take on technical debt to deliver some quick hits, once the underpinnings and architecture are in place, so that you can ship a product on time to the marketplace.

Overall I think it is important to remember that the title of this article is true - in the long term good design is business value. Though sometimes you suspend that temporarily to deliver.

Sometimes business people want results right now and impatience with delivery is seen as a virtue. It can be. If it is a temporary inversion, and not a long term state of affairs.

It can be a real hindrance to long term value if that state of affairs is chronic and without respite.

The decision to switch from the long term view (important at the outset and through most of the life of a project) to the short term view (often important at the end of the project, to deliver on time) is an emotional one.

People don't want to stop designing and they don't like the idea of taking on technical debt. However, it can't be avoided.

Your job as a software development leader is to listen and guide your team through this transition, AND to guide the business back, once the release is done.

Be aware of the emotions and motivations on both sides. Make the smart decision to ship. Also, make the smart decision to switch back and pay your technical debt when the next phase begins.

I think that we need to recognize two important things:

  1. A request to finish fast and on a time line can feel arbitrary to people you need to articulate why.
  2. A request to finish fast and take on technical debt can also appear to be a request to stop delivering business value and do a shoddy job, you should avoid phrasing things so that it sounds this way.
  3. A choice to finish fast is a choice for the business value of now versus the business value of later which can be called many things: time value of money, a bird in the hand is worth two in the bush, or "we need to close this account". This can be a good and smart decision, but it is a decision with trade offs. Acknowledge the trade offs and press forward.