The difference between solutions and creating software – part 1

Share
Share

Poland and Central Europe in general have a very unique opportunity. There’s a lot of tech talent around here, but still, we seem to be building much more software than actual products or solutions. We’re not spending enough time talking about self-organizing teams, context, and alignment. I believe it’s worth it to stop for a moment and take a look at the software delivery process, thinking of it as a journey of managing by context and alignment of success criteria.

Krzysztof’s speech during the Product Camp conference, which took place in autumn 2020:

Listen on Spreaker inwedobutton

Few words about my story from an early entrepreneur to a Founder of the software house

I’m an engineer by training and a builder by passion. I’ve built teams, products, and processes. I started my first company very early – at 16, encouraged by our first Client – Microsoft. Since that time I’ve been around the IT world for more than 15 years. On the way, I became a Co-founder of Inwedo, which is a software house that helps companies to scale through software solutions. 

I also had a chance to fail pretty badly a product company, together with my business partner. But we still work together, so real friendships survive companies that fall apart. 

 

Creating software is more than just writing code

I strongly believe that technology is not only leverage but also a responsibility in the software delivery process. 

 

If you know how to change things around with technology, you also need to think about how you use this responsibility. Because you can put the leverage in different places and you can place your focus on different things. 

 

I’m definitely not a very good coder, I realized that quite quickly. Instead of focusing on programming – I’ve decided to place my focus on building self-sufficient teams, imagining a company that could then – using technology, transform what is around us in a positive way.

 

Context is the new king

Some people wrote that content is king, but I really believe it’s actually context. Or if your mind is set to the original saying, then at least – if content is king, then context is queen. It’s the first ingredient to creating a self-sufficient team. 

Context – and I will use this word a lot in the next few paragraphs – is a tool that puts decision-making in the hands of the right people, usually the ones that are closest to action. 

According to an Oxford definition, context is described solely as a setting in which the circumstances are fully understood. If you look at the definition I’ve made up – you can perceive context as sort of a map, that gives you an insight into a reality in which stakeholders are immersed in. A reality that includes the whole surroundings of what people usually live and breathe by. 

 

Whole Krzysztof webinar you can watch on YouTube:

 

From micromanagement in the workplace to management with context

Starting any project – you have to make up your mind where you want to be with your management style, on a scale from micromanagement to management with context. In my reality, the dimension is often spread between body leasing as a service on one end and trusted advisory on the other. In this world of service and consulting you either sell time and headcount, or you actually make value by providing very specialized knowledge. The sweet spot for myself has to be somewhere around three-thirds of the way towards the trusted partner profile.

It’s very hard to be a trusted advisor and it’s very hard to scale this up further. However, I believe that by adding context and making sure that all team members are familiar with it they’re able to move very quickly towards a trusted advisor landscape, with almost no need for the project supervisor to micro-manage anything. 

 

Self-sufficiency within the team based on understanding the context is a process

If you think of it and look at the definitions above – in every project, there are so many different contexts. Hundreds, and hundreds of various contexts in every company. The goals, the incentive schemes, relationships between people, competitors, personal aspirations, past good and bad experiences, market landscape, and many, many more. There are millions of pieces of context pick up. And to be effective in the process – you need to take care of the team’s environment as well. 

 

Self-organizing teams need to create an environment where people feel safe 

For the self-organizing teams, it’s important to create an environment where people feel safe to be fully present. When the team wants to understand the complex context of the client they’re working with or the project they’re starting, then this safe space is actually a prerequisite. 

We live in very interesting times in many ways, there are so many good tools to actually help to dissipate and spread context in different ways. Slack and Notion are widespread and well-known team collaboration platforms, making self-organization a lot easier. However, they can also be implemented as great context-aligning tools. 

With a team that is composed of people willing and ready to bring their full self to work, be fully present at work, using even very simple tools – it’s the best possible foundation for spreading context. And since it requires conscious effort – I like to think of the process as cross-pollination. 

In an environment that feels safe to everyone around – the knowledge spreads much faster, and the understanding is deeper as no one is afraid to ask questions when necessary. 

 

What with these actions that often feel like a waste of time?

Making a conscious effort when spreading context across the team means that some actions often feel like a waste of time. When you’re spreading context, you can be repeating yourself, asking others to summarize meetings; pushing for updates on Slack – a lot of things that seem not to be producing that much value at the first glance, making you feel like a micromanaging boss. So the natural question here is: who will be responsible to make sure this context is being shared and spread? 

I guess for every organization, especially self-designing organizations, it’s a bit different. But we figured out that

product owner actually is the role in our teams that is best-suited to help to spread the context, both from the customer’s side and between the teams. 

And of course, all team members are involved somehow in this cross-pollination and spread of the context, but sometimes it requires a bit of energy and a bit of effort. And every time this happens, it’s on the shoulders of the product owner to make sure everyone is equipped with the context before they start to actually develop software

I’m curious: have you ever thought about spreading context, cross-pollination of context in a conscious way? And if yes – what roles in the organization were responsible for that? Was that product owners, Scrum Masters, project managers, product managers? 

More about it I wrote in blogpost:

A project kick-off: how to save time and increase success of software development projects?

You can also find something useful here:

Closing a project or phase – offboarding. A seamless way to successful software implementation

 

How to start extracting context? 

Let’s assume we have a team that is equipped with the right tools, knowledge, and mindset to extract context from a customer or a new process, new product. How to start?

Creating software is an iterative process. 

We often forget that the number of iterations that are needed to develop software or to create and release a piece of an MVP is dependent not only on the complexity but also on the starting point and also on how well we define the ending point. 

The starting point is usually the moment where you can go very, very wrong. That’s why it’s crucial to define the starting point at the beginning of a software delivery process, even if there are external pressures not to do that.

 

Start wisely: Discovery Workshops 

Discovery Workshops are not a new concept in the software delivery process. There are many ways to do that through design thinking or in any other way. Every organization has its own way to do it. But the next time you plan a workshop that is focused on defining something, think about this as a Context Discovery Workshop. I usually break this up into three sessions, either full-day or just half-day – as it depends on the complexity of the idea behind this. 

In every session there is a certain goal to be achieved. The first one is about ideas and vision, the second one is about synthesis, and the third one is about the software itself. The software moment comes up quite late, notice that! 

It feels like the idea is expanding at first, then contracting through cutting various less important or lower priority bits out, then solidifying. Sometimes if it is a product or company discussion in a broader sense, we talk about strategies, so the direction and ideas how to achieve the metrics for software development. It’s kind of a tactical approach. In the third session, it’s time to discuss the details of the execution. 

 

Simon Sinek’s WHY, HOW and WHAT approach

For all the fans of Simon Sinek out there, our approach to Discovery Workshops is a different take on WHY, HOW and WHAT. But there is another question that is  often overlooked, and I wanted to stress this as many times as possible. 

If context is the water we’re immersed in, there’s nothing to tell us about the direction we want to swim in

When we think of transitioning from software to solutions, the most difficult and the most important question is: How will we know that we are successful with anything we’re trying to build? 

And that’s when project success criteria come into play.