What is a Project Manager?

Project management is in theory a good idea.

Someone that manages every stage of a project.

From first idea, through various design stages, prototyping, testing, refinement, coding, more testing, deploying and then running a bit of software.

Even with “agile”, self-organising teams (people that don’t need someone telling them what to do) surely someone needs to keep an eye on costs, on timings, on the welfare of the team?

Surely a good PM is constructive, factual, diligent and proud of the team behind their project?

Project management in the real world

The problem is that project management in practice does not really work that way.

There’s a team in charge of design (with or without a project manager).

Another team responsible for testing.

Another team that will deploy any new software.

And a fourth team to support users, maintain and patch the software once it’s launched, to make sure it’s all running just the way it should.

You see the problem?

Too many chefs

Since the early days of Google, people throughout the company questioned the value of managers.

That scepticism stems from a highly technocratic culture.

Even as long ago as 2013, one software engineer, Eric Flatt, puts it plainly, “Google is a company built by engineers for engineers.”

Most engineers and developers, not just those at Google, want to spend their time designing and debugging, not communicating with bosses or supervising other workers’ progress. 

In their hearts they’ve long believed that management is more destructive than beneficial, a distraction from “real work” and tangible, goal-directed tasks.

Add in the duplication of effort when work moves from one team to another.

Let alone the issues that crop up when the deployment and support teams are patching code that they did not write, in languages they don’t understand.

And all of a sudden new tech becomes not just a challenge, but a never-ending cycle of misery.

RIP Digital Change.

Project management and DevOps

DevOps automates the processes between software development and IT teams, so that they can build, test, and release software faster and more reliably.

The concept of DevOps is founded on collaboration between teams that historically functioned in relative silos.

Product ownership

The promised benefits include increased trust, faster software releases, ability to solve critical issues quickly, and better manage unplanned work.

The rise of DevOps has resulted in a huge change to the roles needed in any dev team.

The people writing the code, the people provisioning and supporting infrastructure and the people testing and doing QA all need to change.

As DevOps culture spreads, however, this also has a big impact on project management.

As IT teams change how they approach projects, shifting away from monolithic, multi-month (or multi-year, in some cases) initiatives in pursuit of greater speed and agility, what’s needed is not project management, but product ownership.

The rise of product ownership

Product ownership is all about the move from project delivery to building a team of people that own a product (like a mobile banking app) from beginning to end.

And that means the same team not just writing code, but testing it, managing the QA, deploying it and then running and debugging it once it goes live.

So the days of working in isolation on a piece of code, then handing it over like a piece of a jigsaw, all project-managed and coordinated by a PM, are gone.

CIOs say R.I.P. IT project management

The most successful IT organisations are not order-takers.

In financial services and business information, it’s businesses like ThinCats, Monzo, Beauhurst, CrowdCube, Tide, Anna, Mettle and Revolut that are setting the new rules.

They are innovators.

They aren’t sitting around waiting for projects tossed over the fence.

They’ve torn those fences down.

Now they’re working as cross-functional, co-located teams to drive product strategy and business value.

The very concept of having an IT project with a start and end date is becoming obsolete in the era of digital transformation.

And non-tech businesses – the banks, building societies, credit card companies, airport authorities, manufacturers and engineering firms, need to embrace the same changes, or risk being overtaken by new, more nimble competitors.

Cynthia Stoddard, senior vice president and CIO at Adobe Systems, says that operating in this way removes the mystery about the value IT brings to the business.

“Before, you were talking about projects and milestones, and people weren’t actually clear about what they were going to get,” she said. “Now they understand what they are going to get, how they can use it, and how they can plan their business around it.”

Stoddard and other CIOs and leaders share how they’ve shifted their focus in IT from managing projects to managing products and value streams in the new

Staffing realities 

When it comes to staffing a product management team, a business needs a combination of people with a unique skill set – a combination of technical expertise with creative thinking, and the ability to really take ownership of a product.

They need to be interested in “going deep on a product” and dedicating themselves to one mission.

Some people are just not wired that way.

They like the variety of working on different projects and learning about the business by being exposed to different departments.

Or they are a project manager that likes taking something to a natural conclusion, and then handing it over to another team.

Accelerating digital in a traditional business

As a business shifts to a product mentality, you gain the ability to accelerate digital change.

But from airlines to banks, factories to distributors, businesses that started long before the digital age can find it hard to make the shift.

The business needs people that are brave enough to pivot strategies, change languages, and do whatever is needed to make the change really happen.

Not every team is willing to do this.

Within any organisation, there will always be people that enjoy bouncing around on short-term projects, as well as people that prefer to stick with testing, or with deployment, or with support.

And as businesses move to a model more centred around their own capability, it’s vital that the partners that remain are the sort of people that embrace change.

Creative thinkers.

Product owners.

People that will stick around.

Be brave.

Make difficult decisions (like scrapping 6-months’ worth of code in order to do things a better way).

In this way, the business can build highly effective teams, led by people from companies like Slate that think in a product-focused, creative way.

Gaining a sense of ownership – and speed

Any move to product ownership isn’t fool proof.

There will be people who prefer the variety of project work, and can’t function in a product ownership model.

And there will be teams that are too big to build the strong relationships that allow them not just to own the product, but to collaborate and work closely as a team (at Slate, we cap teams at 25 people, and we think clients would benefit from doing the same).

In a product ownership mentality, you’re part of a team all year long, year after year, instead of just a short cycle of the project.

People feel ownership, and there’s a strong sense of camaraderie that there can never be in the old project management world.

With monthly sprints, for example, a business can roll out new upgrades every month. You’d have a tough time doing the same while working on a project basis.

Slate typically start a new client engagement with just 2-4 people, and then build out product management resources from there in line with the skills inside the business, to accelerate digital change.

Slate inject amazing people into organisations to help clients to help themselves. If you’re a big corporate looking to hire the best, or a developer looking for a new challenge, get in touch.