Non-Technical Delivery Ownership FAQ

Roger Creyke
Sep 1, 2018 · 10 min read

Suddenly being put in a position of responsibility for delivery from a team of software engineers either as a team lead or as a product owner can be a daunting challenge, the complexity of which can be amplified significantly if you lack an engineering background.

You may feel a lot of pressure to immediately “deliver value”, “solve output problems”, or “push the roadmap through”.

Here’s some questions you may ask if you find yourself in that position.

Why can’t every work item directly deliver immediate quantifiable value to our customer?

All but the most trivial of software systems require work outside of feature deliveries. Code rots if it is not taken care of.

Consider a kitchen in which the chefs turn up to work and cook for their entire shift. This can yield fantastic output for the first day, but things immediately start to go south after that. Pans pile up. Things get messy. On the second day less meals will be delivered to customers, probably of a lower quality. After a while the entire kitchen will be unable to function, even if it still somehow has the morale to want to. Customers are obviously affected and lose confidence in delivery and quality.

In the world of software the ongoing processes required to prevent code rot include removing code which is no longer used, restructuring code to ensure it can be easily maintained as the requirements of it change, writing tests to ensure code achieves that which is expected of it in terms of performance or functionality, and keeping the technologies used by the team up to date to ensure the team remains productive and the product receives the necessary security updates.

You need to allow a percentage of time to these activities and allow the senior engineers in the team to prioritize them.

But can’t I get the most output for as long as possible and worry about these problems later?

Long term this is a death sentence for the project. You should very rarely try and avoid code maintenance. An exception in a kitchen might be deferring washing up from New Years Eve to New Years Day but these situations should remain rare. If you want to do it, explain to the senior engineers in the team why this is so important and get their buy in.

If you more regularly treat code in this way, you will build up technical debt which you will need to pay back and your output will continue to suffer until you reach a point where the cost of doing the work is higher than the value it yields and then your product is dead, and you will affectionately be referred to as a product killer.

I’m off this product in a year and on to the next rung of my rocket-ship career ladder. Can’t I defer the debt a year?

The engineers will probably be on this particular product for longer than you, so unless you don’t mind sullying your reputation, ruining their future job satisfaction and risking damage to your company for short term personal gain, no you can’t.

But I don’t care about my reputation or the job satisfaction of my resources, so it’s ok right?

You may want to take a sociopathy or APD test, and you should probably stop torturing small animals for fun too.

Why don’t my resources respect me?

Firstly, when it comes to earning respect it is detrimental to refer to members of your team as “resources”. They are skilled workers who have spent years learning their craft and contrary to popular belief, unlike hardware resources or alcohol resources, they are not something you can easily scale up or down.

There are plenty of other terms which don’t have these negative connotations which include but are not limited to “team members”, “engineers” or just “people”.

Other offensive terms include but are not by any means limited to “code monkeys”, “grunts”, or “pixel pushers”.

Secondly, if you are a product owner in a scrum style environment, these people are not “yours”. The team lead, who may be the scrum master, runs the team. In this case, you are there to articulate and prioritize the business requirements, and its important to respect those roles and see the team lead and/or scrum master as partners and not subordinates, or you will indeed lose their respect and that of their team.

My scrum master is measuring work in terms of complexity as opposed to time. Why can’t we be accurate on our estimates?

If someone makes matchboxes and made 100 today, you can accurately estimate they will make 500 during a 5 day working week.

If you want a computer to do exactly the same thing repeatedly, you can give it one set of instructions (a function) and tell it to execute that function as many times as you want.

However, most product features require new functionality, and therefore new code. In most cases, this will be the first time the engineer working on this product has done exactly this thing to this product.

Which means almost every new feature requires research, code, and tests, the depth and complexity of which has to be estimated.

It’s simply not possible to be exact about how long software development takes because it is not an exact science. Using complexity as a gauge enables a team to combine their estimates for many features across a time frame (often referred to as a sprint), knowing that they can normally deliver a certain number of complexity points within said time-frame.

If some things take longer than expected, hopefully some other things will take less time than anticipated. That’s the best you can do. Deal with it and add padding or you will fail.

But we have real world hard dates for delivery of features. How do we reconcile them with such imprecision?

Work on the hard date stuff first. When it’s done, do the stuff that doesn’t have a hard date.

Don’t give too many features hard dates. An agile roadmap should not be exhaustive or exact. This will make you inflexible, which is the inverse of being agile. If you are not agile, you cannot change focus when a new real hard date comes along, because you already have too many hard dates committed.

If you are a product owner, you are responsible for managing expectation. Don’t over-commit the team or you will have to beg them to overwork and both quality, and your relationship with the team will suffer. You will achieve less the following month because people will be burnt out and there will be technical debt to pay where corners were cut.

Here’s the hard truth, and the sooner you learn this and the less pain for everyone.

The customer will always want more than you can give.

Don’t be a yes person. Learn to say no at the correct point — that point is the point at which things become infeasible. This is how you build a good relationship with both your customers and the engineering team.

Why do my resources keep insisting we create unit tests as part of a feature? I need to ship faster?

You said resources again. Look, they are the experts, if they feel they need unit tests to ensure a feature functions correctly and can be maintained going forward, then you need to see those tests as part of the feature. You wouldn’t tell a builder to skip the structural integrity validation would you? You would? Please can you take the sociopath test again then just to make sure.

If an engineer insists on unit testing every line of code, and you are not building missile guidance software, maybe they are getting obsessed with unit testing and you should (via a team lead if there is one separate to you) challenge this.

Why are we always reinventing the wheel?

It can definitely seem like this. Some features seem like they’ve been asked for in a thousand other products. The problem with software is that if the feature has to sit deep in your proprietary product, it may be hard to use existing code.

Even without a technical background, in time you should be able to get a feeling for what requires fundamental product changes, and what can safely be purchased / acquired and tacked onto the side of an existing product.

Challenge the engineering team and ask them to explain why you have to build something from scratch, but if you are repeatedly disagreeing on this then this is a big problem — they are the experts and you should generally trust them to decide.

Understand what your core business is, and where it stops. Don’t encourage the building of products which are outside of your domain of expertise as a company. These are just vanity projects which will almost always be orders of magnitude more expensive than paying for a service provided by experts in that area. Even rarer do they yield a more compelling product. The engineers will be miserable because they are building something they know sucks in comparison to the industry leaders.

Some things your business should never ever build (unless this is the reason the business exists) include a company chat application, an issue tracking system, a payroll system, an HR system, an expenses system… you get the idea.

How do I deliver more value faster?

How do you define value? That’s the first thing. Your definition will probably come from people above you. Hopefully its a sensible one like how much money your product makes, how happy people are using it, or how long people spend on it. Whatever it is, it needs to be measurable.

Features are not value. Not all features add value. Many take value away.

Stop concentrating on the delivery and start concentrating on prioritization. It’s not your job to push the team to deliver more — it is your job to tell them whats the most important thing to do next. When you have a healthy, happy, high quality team, and mutual trust between them and yourself, then you will start to see the delivery.

In almost all scenarios, quality is everything. Ensure the product does a few things brilliantly before you add more things. If you throw everything in at once without giving enough care to anything, then you’ve delivered a lot of features but probably very little value.

Don’t add every feature you are asked for. Some ideas are stupid. Protect the product from them and have a clear definition of what the product is so you can articulate why the inclusion of a particular feature is detrimental.

I believe a 12 year old kid I know can build this quicker. Is it a good idea to tell the team that I think this?

That’s a terrible idea! If you have a problem with output then talk to the most senior technical person and try to understand what is wrong. Work with them to resolve whatever that is but don’t have some meltdown in front of the whole team. It’s likely they can’t just flick a switch to fix the problem and will need buy-in from the wider business to do so.

Professional products with a higher quality take longer to build than prototypes. Little Timmy’s website serves 10 users a day.

Also had you considered that your mate at ReallyGoodSoft who says their “ninja” team delivers to production “200 times a day” might be a compulsive liar?

Why can’t I throw more resources at the problem?

Because the problem is one of cohabiting a number of highly skilled people within a code base of finite depth and breadth. You can only make so many changes to a piece of software at the same time without tearing it apart.

If you really need extra capacity you need your monolithic product to be broken up into smaller self-sufficient loosely-coupled components (the buzzword currently is “microservices”) and then you can distribute the ownership of these among multiple teams.

On well established codebases this change can often be a large technical undertaking, and you will go slower before you go faster.

On products where automation is lacking, investing in it may return quicker rewards. For example build automation, test automation, deployment automation etc; engineers will be happier (because they hate doing the same thing repeatedly), and they will also be freed up to have more time to work on new code.

You will also get a more reliable product out of it too, because humans are notoriously bad at repeating the same task reliably, and errors creep in where automation is lacking. Reliability means less problems to fix, so more time for new features. Note the repeating theme that delivery is not a goal, rather it is an outcome of other goals.

Why does my team insist on code reviews?

A professional team will ensure at least two people see every line of code that goes into a product.

One line of careless code can bring your service down for days. One line of malicious code can steal sensitive data or expose it on the public internet.

Don’t trivialize or obstruct this process. It is one of the minimum requirements for professional software development and one of the very, very last things you should ever cut for time.

Should I outsource key parts of my core product to a team in Antarctica to bolster capacity in order to get short term approval from the executive?

No! What does an outsource company care about your code? See the question above. This is short term gain, long term hell.

If you have to outsource something, make it entirely self-contained, and not the core product or anything that could become the crown jewels.

If you have to outsource any key part of the product, you will have to take the hit of having a trusted senior engineer defining standards, and reviewing all code incoming until permanent engineers are hired to look after. And don’t be surprised if they want to rewrite it because they have no affinity to that code and a limited understanding of it, which makes engineers extremely uneasy.

What are the implications of doing 4 hours more a day, every day, for 2 months? Can we deliver more by throwing money at people?

More output in the very short term (first two weeks). Then burnt out engineers medium term along with technical debt which needs to be paid anyway. Long term distrust in your ability to contribute to a software product or manage expectation.

What does success look like? Is it big pushes every so often? Or consistent sustainable pace?

Sustainable pace. Expectation managed. Big pushes once or twice a year due to exceptional unforeseen circumstances.

My engineers keep coming up with “ideas” or “improvements” in addition to the specific requirements I’ve given them.

Listen. Pick your battles. Engineers are creatives. They also want to add value. Good ones look for the best bang for buck and there will be some gems in there that can add real value which neither you nor the customer ever considered or understood was possible.

What are the motivations of my technical team?

Diverse. They are individuals. But aside from the obvious things everyone wants in a job there are some common traits in almost all engineers. A drive to produce high quality products. A need to feel they are adding value. A want to continue to keep their skills relevant. A desire to work with modern technologies. A fast PC.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade