lidenskap.blog

The truth?!

What's the truth?! The truth is not delivered by authors and authorities anymore but is assembled in real time piece by piece by yourself.

You make your own content and construct your own truth from the liquid stream of facts flowing through the web (hyperlinks, text, videos, images, sound). For every expert you will find an anti-expert. We have to constantly question what we think we know.

The status of creation will be inverted, so that the users, you, become the new creators. You will be a creator of digital products and content used to do your job.

Do we need more answers or better questions?

Technologies that help generate questions will be valued more. Question makers will be the engines that generate new fields. Questioning is simply more powerful than answering.

"The Inevitable" by Kevin Kelly

History's role is not to help us predict the future, but to prepare us for it. 

Jim Highsmith's career over the last six decades is a good start.

In the Wild West Era (1966-1979), software engineering was in its infancy and the knowledge of how to "do" software development negligible. This era was wild.

The Structured Methods and Monumental Methodologies (1980-1989) era was an attempt to go from the undisciplined wild west to a more disciplined and formal approach, trying to be recognized as an engineering discipline. 

IT projects were generally viewed as out of control, and business managers assumed building software was the same as building a warehouse. Focus on tasks rather than people and team dynamics.

A formation and expanded use of waterfall, control-oriented, and process-heavy methodologies emerged assuming that documentation was sufficient to communicate between groups with no need for further explanation. Variation from the plan was seen as poor execution.

Despite of this, the approaches managed to deliver value. The success and failures of one era form the base for the next.

"IT projects take too long, costs too much, and don't meet our needs". Welcome to The Roots of Agile (1990 - 2000). In response to executives cries for help, software developers began experimenting with iterative Rapid Application Development (RAD and RADical) methodologies, especially for Internet applications.

• "It was just a small project", 
• "It was a new project", 
• "They didn't have to follow our standards".

Management wanted agility, but with traditional performance measures. To change behavior and culture, you must change measures of success.

In the current Digital Transformation period (2011 - present), the problem isn't scaling Agile, but enterprise-wide scaling of agility and innovation. 

We need to move from predicting and planning for the future, to building a platform that enables us to adapt to whatever happens.

Preparing for the future challenges us to scale an agility mindset, not simply agile methods and methodologies.

What advice do you wish you had when you pursued your first leadership role?

Steffan, you will now go from the guy making recommendations to the guy making decisions. You go from being an individual contributor to delivering through others. You now lead a team of people doing what you used to be good at, that got you promoted in the first place.

That's a big change. How to make good decisions, facilitate a meeting, craft a strategy or delegate work is not something that everyone naturally just know how to do. If you think they are natural abilities, then you might feel there's something wrong with you if you don't have them. Please don't. It's a skill you can learn. You will do mistakes, but over time you will nail it. Leadership is an education.

People is your work now. Invest time in them, be present, be available. Listen. Ask how you can help all the time. Then comes communication, communication, communication, setting budgets, performance reviews, 1:1 meetings, meetings with stakeholders, recruitment, setting goals, prioritize, help finding solutions on complex problems, solving conflicts.

Don't forget to take care of yourself. What gives you energy? What drains you for energy? What do you need to do yourself, and what can you delegate to others? Do one thing at a time. Use your team. Create a support system around you, and use it. Block time in your calendar to think and reflect.

Never create a bunch of tasks that you assign to your team for execution. Provide context, intent. Let your brilliant team and problem solvers define and own their tasks and actions. A good plan developed and understood by the team is better than a "brilliant" plan by you.

Don't stress if you don't have a vision on the first day. You are not Steve Jobs. Visions can be found. Find it together with your team and let it be the compass in everything you do. What would you like to achieve together? What's the future we are trying to create? How do we plan to accomplish that? Let it become theirs, not only yours.

Watch out for compromises in this process. If you try to come up with something that pleases everyone, you end up pleasing no one.

Steffan, you are not a super human and don't pretend to be one. You have your strengths, but also your weaknesses and gaps. Your job is to build a team and surround yourself with people closing those gaps. Your job is not to know everything.

There will be periods where you doubt yourself and question everything, but suddenly you will see someone on your team achieve more than they thought they were capable of.

You will see your team come together to solve impossible problems. You will see a team that would do anything to help each other out. Impact. That's the joy of leadership. That's your reward. That's the reason why you became a leader.

Good luck my friend!

Best Regards,

Steffan Sørenes, a year older and (somewhat) wiser

A potential minefield. 

The high energy from ideation and brainstorming quickly turns into frustration when it's time to make a decision.

We don't fully control the outcomes from a decision, but what we have some control over and what we can improve is the quality of our decision process.

A challenge is that we often want to accomplish two things at the same time. 

We don't want to waste too much time, and we don't want to sacrifice too much accuracy. The key to balancing this trade-off is figuring out the penalty for not getting the decision exactly right. What's the worst case that can happen?

So you have a list of ideas coming from your team, but which of them shall we pursue? There will always be one that is accountable for the final call, but there are many ways to accomplish it.

Shall we do an individual ranking where each idea must pass relevant thresholds, or shall we rank them relative to each other? What are the selection criteria to assess? What's your current constraints and non-negotiables?

Shall you do it democratically through voting? Voting is time effective and consistent. Will everyone feel a part of the decision through voting? Do you get rid of groupthink? In a voting there will be limited information and knowledge flow between the team members. Do we want that?

Or shall we just appoint a leader that makes the decision? That's probably effective, but the quality of the decision depends heavily on the leader's style and knowledge.

Will the leader involve and listen to each team member's opinions, and change their own opinions if needed? Will the leader share their thought process afterwards?

Or shall we aim for consensus? Done right, consensus can result in a high-quality decision. You share information within the team, everyone hears what everyone else has to say and can ask questions to each other. Team members also share responsibility (if not, is it true consensus).

However, consensus takes time. It's slow. At least for a new team. It can easily break down without the right team dynamics and guidelines. Does it feel a bit "leaderless"? 

And is it not a short distance from consensus to compromise where three good ideas are turned into one bad one to please everybody.

What about the consensus trap where everyone seems to be in agreement but in reality the majority disagrees without speaking up. What do you do if not everyone agrees with you at the end? Some companies swear to "disagree and commit".

Gerald Weinberg said that the trick is not to know the best method, but the best method under the present circumstances. The most effective leaders are the ones who help the team to recognize when circumstances change and to find a new decision making method that fits.

How do you make decisions in diverse groups and teams? Which forms do you use under which circumstances?

Many have witnessed failed transformations, but few have witnessed true successes. 

Moving to the product operating model is a transformation. At the end, it's about consistently creating technology-powered solutions that your customers love, yet work for your business. It's about delivering real results. But what do you change exactly?

You change how you build. Products are managed as an ongoing effort - improving every week until it's decided to sunset it. You do frequent, small releases so you know that it's working and how it's being used.

You change how you solve problems. Empowered product teams are given problems to solve and outcomes to achieve instead of a list of prioritized features, projects and perceived solutions decided by various stakeholders.

You change how you decide which problems to solve. A strong product company has a compelling product vision and insight-based product strategy identifying the most critical problems that need to be solved to deliver on the business objectives. Your strategy cannot be to serve as many business stakeholders as possible.

Pushing the decisions and responsibilities for finding the best solution to the problem down to the relevant product team, and then holding that team accountable for the results also drives the need for new product core competencies (that normally takes years to learn). 

Unless you are willing to establish these new competencies, your transformation hopes will likely end here.

For the product team together with the product manager to discover and deliver effective solutions, it is absolutely critical that they have direct access to:

1. Users and customers,
2. Product data, 
3. Business stakeholders and
4. Engineers (the tech lead as a minimum).

Fight any attempt to place a well-meaning person or cumbersome process between the product manager and these constituencies.

An honest and accurate assessment of the organization’s current situation is essential to any plan to successfully transform. Be realistic, talk to all levels and look for evidence. 

Start with pilot teams volunteering to be on the leading edge of these changes. Develop the skills of the product teams (bottom up) and the skills of the product leaders (top down). Ensure your CEO supports and is a champion of the change.

Transformation is a long game, and for that reasons it helps to have some quick wins. It could simply be a team that has never visited users starts doing do and shares it experiences and insights. 

Constantly beat the drum, evangelize and show everyone the progress being made.

"Transformed - Moving to the product operating model" by Marty Cagan.