Episode description

On this episode of madewithlove’s Pulse podcast, we’ve invited Mike Veerman (Software strategist) to discuss with our own Vinch Battaglia (CTO in residence), Jonas Drieghe (Software engineer), and Dimitri Van Lunter (Engineering manager) things like:

Introducing… Mike Veerman

Mike Veerman has been in the tech space for the last 15 years and is now helping build software products as a consultant. He came a long way from working as a software developer to doing project management and even some agile coaching.

What is a software strategist? Between technical leadership and software development

Mike noticed that combining the two worlds — hands-on software development and managing engineering teams — is what’s missing in many tech organizations. When people think of a developer, they often think “translating JIRA tickets into JavaScript” and the mental picture of a project manager is basically a suit with post-it notes. So Mike came up with a new role.

He likes to call himself a software strategist, someone who puts software projects (back) on the rails. Having worked both as a developer and a project manager, he’s able to oversee the entire software development process — not just as an idle observer, but also as someone who’s not afraid to step in and get his hands dirty.

“I basically help teams keep an eye on the big picture, but I also get along while they’re doing that.”

A day in a software strategist’s life

While a software strategist is an interdisciplinary role (you can read more about different roles in a software engineering team in our article about assessing seniority of tech professionals), the daily tasks can be categorized into two buckets:

  • The “I’m part of your team” bucket — being embedded in a client’s team, helping them tackle technical problems and provide technical leadership for a couple of months.
  • The “Let me guide you through this” bucket — showing clients the best direction for their product development, while still (occasionally) helping to tackle practical software development challenges.

Oftentimes, a software strategist is responsible for taking a business through a digital transformation and that’s what we discussed with Mike in the first place.

Digital transformation in 2021

digital transformation

Software technology used to be an add-on, something that many companies could easily survive without. Nowadays, every company is a software company, especially since the COVID-19 pandemic forced people to work remotely (which leads to many issues that we describe in a series of articles) and become more creative with the way they reach their customers.

What is digital transformation and why it’s now a buzzword

The term “digital transformation” is one of those terms that everybody sort of understands, but it’s difficult to find one precise definition for it. Mike’s definition goes like this:

“It’s usually used as a buzzword to sell more consultants.” 

Or, on a more serious note:

“The way you look at your industry should be a tech-driven vision. That’s what digital transformation is. A tech-driven vision.”

Starting a digital transformation in 2021 is many years too late, so if you’re still stuck in a pen-and-paper world, you might consider replacing your management.

But how do you go from an old-school business model to creating automated, digital processes that can be scaled? Let’s take a look at a few examples.

Examples of digital transformation — from restaurants to governments

Mike brings up Netflix as one of the best cases where a physical, very manual business (they used to mail DVDs to their customers) became a digital giant, the biggest streaming platform in the world.

COVID-19 forced many eCommerce business to catch up with the “big guys” and so many restaurants and shops had to rush into a digital transformation:

  • Restaurants introduced online booking systems and started relying on 3rd party delivery platforms like Deliveroo;
  • Shops had to invest in transactional websites and integrate with digital systems for handling payments and delivery.

Those kinds of changes started happening years ago, so the pandemic was a very needed push that caused some businesses to fail and disappear while others finally lived up to the industry standards (in terms of digitalizing their services).

Digitalization has become a commodity for traditional services, too. One example is government job sites (the UK’s HMRC site is sometimes considered a user experience benchmark for many aspiring startups). It’s been a long and painful process, but nowadays people are surprised when they are not able to do something online, whether it’s ordering lunch or applying for a government grant.

“Digital transformation isn’t visible, because we consider it normal these days.”

The state of digital transformation isn’t as bad as consultants tend to make their clients believe. But why are there still businesses that resist this inevitable change?

Digital transformation is scary… or is it?

The mental pushback from old-school management is sometimes more difficult to overcome than the technical process behind the digital transformation. Mike says that everybody he’s worked with wanted a change, but they were discouraged by the way that change had been proposed to them.

“In general, people like the change, but they don’t like being changed. Giving them the opportunity to drive that change and to see where that change should be headed is valuable as a consultant. Telling them what to do is pointless.”

The worst thing that an external consultant can do, something that scares their client away, is to tell them what to do without holding their hand through this process. There’s an extreme arrogance in this stand-and-watch approach. A consultant shouldn’t be a change agent, bossing around employees who have worked in their company for a decade. People don’t buy that.

The paradox of progress

There’s also a completely different dimension of fear. Some employees, especially those doing manual work, are afraid of losing their jobs because they realize they can be easily replaced and that it can happen sooner than they hope.

The jobs we don’t need, but they still exist

In manual labour, people are quickly being replaced by robots. We’ll see that in the office environment as well. Products like AWS can take away work from multiple team members at a time (database managers and people maintaining application servers). Many highly-paid jobs can be replaced by technology.

leadership remote

Capitalism has manipulated us into lowering labour costs and driving automation and digital transformations. Politicians want more jobs and they want to keep positions that could be easily replaced by robots or software.

Keeping jobs just for the sake of paying people is pointless.

“We need to make sure that people are not economically forced to do meaningless jobs.”

Mike brings up an example of a man who is paid to approach people in a parking lot and ask them if they need to change money. Instead of wasting time (and life) on tasks like this, such as maintaining software that nobody uses or keeping an application server onsite when it can be run in the cloud, we should create meaningful, technical jobs. But this change is very uncomfortable because it leads to firing people who, for that reason, resist it.

In the podcast, we’ve discussed a few books that cover this very delicate problem of progress versus people:

Most business changes are initiated by management. We can simplify things and say that there are bad managers, good managers, and then there are leaders. But even leaders can be bad (and often are).

Bad leadership (military) vs. good leadership (José Mourinho)

Mike used to look up to the management, thinking that they know what to do and that they know what their customers need. Then he “grew up” and realized it’s not the case:

“Management is panicking in a meeting room late at night, coming up with a plan that’s unfeasible but good for now.”

Being a boss does not translate into being a leader. Our traditional perception of leadership is based on one person holding the baton and “leading” the rest of the team towards a common goal. Modern leadership is based on multiple people being leaders, depending on the area and context. It’s also not something you inherit with your job title. It’s much more than that:

“Leadership is not something you can take up. Leadership is when other people decide to follow you.”

People like Musk or Zuckerberg are tech visionaries and leaders because they understand what they are building. We can blame lack of product scalability or slow progress on bad leaders, but software engineers and developers are very often accomplices in these crimes. 

This might become an unpopular opinion, but here’s a scenario that we know all too well — a manager talks about new directions for a product, leaves the room, and all the people who are responsible for delivering new features just roll their eyes and decide to “go with it.” 

Tech professionals are often introverts and don’t want to confront the management, but more developers should take up leadership roles, to drive digital transformations in their organizations. Check out this article where we talk about developing engineers into leaders.

Leadership is not a competition. You can have a team of 3, 4, 5 leaders, each responsible for different elements (such as coding, user research, and testing). We should move away from the military linear hierarchy and become more like José Mourinho.

Yes, this José Mourinho, the coach of Tottenham Hotspurs who was humble enough to recognize that he can only lead his team in the area of his expertise, leaving the other leadership fields to the players:

leadership styles
LONDON, ENGLAND – JANUARY 22: Jose Mourinho, Head Coach of Tottenham Hotspur talks to his players in the tunnel at half time during the Premier League match between Tottenham Hotspur and Norwich City at Tottenham Hotspur Stadium on January 22, 2020 in London, United Kingdom. (Photo by Tottenham Hotspur FC/Tottenham Hotspur FC via Getty Images)

“I’m not here to tell them how to play, do this thing or that thing. They know better. I’m here to coach the team—not the players—to make sure they can work together.”

And so by now, we know that software projects and transformations can go wrong because of fear or bad management. But there’s a third variable in this “failure equation.”

Project scope — why the size (of your ruler) matters

The term “project scope” is very well-known in the project management lingo. Planning resources, creating tickets, and working towards long-term deliverables is what makes project managers excited and giddy. In software development, it’s equal to setting yourself up for failure..

Projects fail when you get too greedy

When you develop a software product you need a small-steps approach. Work on one thing, be it a feature, design element or anything else, and then “stretch it.” Build upon what you’ve created rather than jumping on another unrelated ticket just because it’s in the product roadmap.

“The reason why projects fail is that people are trying to hunt a mammoth, while they haven’t caught a mouse in their life.”

Mike wrote an article called “Scoping is a lie” which went viral in our Slack workspace and encouraged us to invite Mike as a podcast guest. We recommend reading the article, but if you don’t have the time right now, here’s a discussion on the main ideas it covers. 

(Project) scope is not a realistic concept

Jonas thinks that Mike’s article is more philosophical than literal, and it describes software development as an art.

However, Mike, being the author, disagrees, because a painter can decide when their work is done, while a software developer always has something to improve. Our podcast guest thinks that project management doesn’t apply to creating software, because it’s about creating an ever-evolving product, so, by definition, it’s impossible to talk about traditional project scoping.

Think about it this way — scoping is like trying to measure the length of the UK’s coast. It’s possible, but you’ll get a different result if you use a 1-meter ruler than if you use a 20-cm ruler. The smaller the scope, the more potential improvements you’ll discover.

All project management tools are built around the idea of getting something done, which is not the case in software development. Saying that you can scope agile projects once and then just tick off the checkboxes on your to-do list is a big, fat lie.

“Software is done when the last client abandons.”

Scope will change every time someone thinks of a solution that’s better than the current one. And there’ll always be a better solution. Does it mean scoping projects is something developer teams should forget? Not necessarily.

Why project scoping still works in 2021

Defining the scope of a software development project is about breaking down the product development process to make team members aware of the steps they need to take, in order to develop features. Then, when approaching each step, engineers will become aware of new problems to tackle.

That kind of external, consulting-like help is necessary for less senior teams working on gigantic software projects, especially if they are greenfield projects. This is where someone from the outside (be it an auditor) can lead the team, show them the right direction (scope) and participate in that transformation.

That kind of external, consulting-like help is necessary for less senior teams working on gigantic software solutions, especially if they are greenfield projects. This is where someone from the outside (be it an auditor) can lead the team, show them the right direction (scope), and participate in that transformation.

If you’re interested in the way we (at madewithlove) audit software businesses, take a look at our audit page where you can download a mock technical audit report for free.

The concept of having tasks to finish is still necessary for asynchronous teams. It’s not the ticket that’s the problem. It’s a list of tickets that is referred to as a “project scope.” The idea of having 15 tickets in your backlog and thinking that when they’re done, the project is done — this is not the definition of scoping that works in software development.

So in an ideal world an engineering team wouldn’t define scope and they would just “go with it,” working on one improvement after another. But it’s not the most sales-friendly approach when a consultant or an agency creates a proposal. How do you scope an agile project if you don’t know where it’ll go?

Waterfall is for building factories. Agile is for building the future

It used to be much easier to productize this kind of technical consulting. Back in the day, when companies were building software based on the waterfall model (a list of deliverables, where each deliverable could be approached only after the previous one was finished), you’d just list the high-level development steps you’d be working on. And then the client was happy because they knew what to expect. Except they didn’t.

The waterfall model is optimized for creating the illusion of control while the agile model is optimized for discovery and action. You can’t create a backlog of things and then clear them out one by one. That’s not how software products are built.

agile leadership

It’s impossible to have the benefits of the waterfall model with the agile approach. You can’t “plan” to create the next Netflix or Facebook before you start working on your platform and learn which new features are required. Small steps — not big leaps.

A high budget can destroy creativity when building software

Ironically, companies with an almost unlimited budget and resources are more likely to fall into a trap of traditional project management instead of doing it the right way. When your only constraint is imagination, you start to focus on big ideas and long-term roadmaps and you forget to take small steps.

The issue is also that many companies still rely on yearly budgets. They plan a big sum of money to spend and they are determined to spend it; money dictates product development directions when instead this should be done by tech leaders, learning from the small chunks of work they’re delivering.

On the opposite end of the spectrum, small teams with a limited budget often go for creative solutions that they can iterate on. That’s how you optimize software development. When you have a lot of money, you’ll end up generating a lot of waste (time, work, features) which is the exact opposite of lean.

How to price technical consulting services

Many agencies ask their clients to pay hundreds of thousands of dollars and they promise to take their product from A to B within a certain amount of time. This is wrong on so many levels we’ve already discussed, but that’s what companies that hire external consultants are used to. And, as we now know, it doesn’t encourage creativity nor applying the rules of technical leadership.

The ideal solution when talking to future clients is to ask about their budget, to build constraints within which you can create a solution, almost like an MVP. Then, you help them work on something that generates revenue (as quickly as possible) and once that’s done, you build new features upon it. Avoid jumping to another to-do just because the client wanted it in the product roadmap.

Keeping your dream team of technical leaders

Our conversation with Mike Veerman was eye-opening. Here’s our main takeaways:

  • Software businesses need tech-driven leaders who should be considered experts in their disciplines and ready to step in to change the direction of product development if it’s concerning from their perspective.
  • The “fear of change” is more about people being afraid to be replaced and lose jobs due to digital transformations than it is about people not wanting a change. More and more tasks can be done by software, so encouraging employees to work towards progress is almost like asking them to work towards their own unemployment.
  • Traditional project management doesn’t work in software development. It’s counter-productive to define the project scope and simply work on predefined tasks, just to be able to say that the product is finished. It’s never finished, and that’s why an engineering team should start small, take a step-by-step approach, and improve on what they build.
  • When a software development team has a very high budget, they often lose creativity that they’d have to rely on when working with more limited resources. So it’s smarter to first define your product development budget and then decide what to build within it rather than to do it the other way around and build expensive, unnecessary features just because you can afford it.

What if you manage to tackle all these problems? What if you create a team of technical leaders, a team that will follow an agile development process and always try to improve rather than blindly build? Well, then you need to find a way to keep your team together.

More on that in future episodes. Sign up for our newsletter (below) to get notified when they come out. Who knows, maybe by then you’ll have your dream team and we’ll be able to help you keep it happy and productive?