Making Better Use of Engineering Teams

collaboration

collaboration

By Mark Littlewood Business of Software hosted Marty Cagan, founder of Silicon Valley Product Group earlier this year in London for a talk based around the new edition of his book, Inspired: How to Make Tech Products Customers Love.He made six primary points on making better use of engineering teams.

1. Provide Engineers with Full Business Context.

Far too many CEOs and executives ‘protect’ their team to the detriment of progress and innovation. They think engineers just want to be left alone to code and not be worried by the rest of the world. Managing Engineers like this leads to bad outcomes.

2. Provide Engineers with Access to Customers.

Magic happens when engineers see their customers face-to-face. This is NOT the same as watching them work on a video link, a research report, or a piece of market research.“They need to be with people in person to understand the visceral motivations of the customer.”“How can we drag them away from their coding for an hour which is what they love?”It’s true that not all engineers are into this, but at least some of the team should be.  If you don’t have any engineers that actively want to do this, you haven’t got the right team.

3. Provide Constraints NOT Requirements.

Think about the Jobs-to-be-Done, not requirements to deliver. Engineers are smart people and can make good decisions given the right objectives. If they are simply told to deliver X, you get what you deserve.

4. Provide Engineers Time for Discovery.

There are lots of different techniques – Jobs-to-be-Done, Design Thinking, Discovery Sprints.  There are even techniques to manage your techniques these days. However, there are no silver bullets, all have strengths and weaknesses, and you need to be able to choose the right one for the job.“Most companies are much better at delivery than discovery.”Agile is about delivery, not discovery. Move fast = discovery.  Don’t break things = delivery.  Lean Startup is great when it is used properly but terrible when it is used inappropriately or badly. An MVP CANNOT take 4 months in discovery. You can do 15-30 iterations a WEEK in discovery.

5. Measure Product Team by Results not Output.

Understand the OKRs and focus on business results your engineering teams deliver, not the amount of work they do.

6. Align Engineers with Competent Product Managers.

Too many product managers just have a Scrum Certificate as qualification.  You need something like that as a minimum, but that isn’t even 10% of the job.“Should the Product Manager be the CEO of the product?”This is a controversial point for many as they are usually NOT the CEO.  Except in the startup phase, but they ARE like the CEO, as they need to understand all of the aspects of the business – user acquisition cost, engineering, design and UX, legal issues, compliance issues, marketing, on boarding, contracts, sales channels.  Great product managers need to be able to look across the business.“The only other role in the company that is like that is the CEO. Even if the product manager doesn’t have the power and authority of the CEO, that's what makes it a super hard job.  It's the hardest job on the team.”

We Couldn’t Agree More.

Of course, it’s true that if Product Managers understand how all of the pieces of a business work, they will do a better job.  So why isn’t this also true for other parts of the business? As Marty suggests, getting engineers in front of customers helps build better products. Equally, if marketing people understood the motivations and constraints that other departments of the business, wouldn’t good `just happen'?

null.png

Mark Littlewood CEO of Business of Software.

Variously described as ‘a world leader in connecting people’ and ‘the one in the terrible shirt’, Mark runs Business of Software Conference, the legendary single-track event for people building profitable, sustainable software and SaaS businesses. He has spent 30 years in the tech sector collecting great people and ideas and connecting them to customers. Prior to Business of Software, he was part of the founding team at Library House, an investment research business based in Cambridge UK serving the global venture capital & banking communities. He led the business development activities for the organization & built a network of angels, early stage, venture & corporate investors.

Previously, he worked with university spin outs; ran a 40 person consultancy business; & founded a web portal for the CAD community. Mark has worked in the publishing and information sectors & attended Trinity College, Cambridge. He tweets at

@marklittlewood.