Tag: Leadership

Categories
Engineering Hives and Silos

Do Not Expect Strategic When Asking for Tactical

The story goes…

The program – has lofty goals for transforming the way to do business, to catch up with challenger businesses (have not kept up with customer expectations).

The first few projects – identified and added to the project portfolio plan for the year.
As for the rest – there is no budget (only planning for the year), or no appetite (the sponsor may not be around next year).

The very first project – it must respond to the immediate problem (after all that’s how the program got the buy-in).
It must do that quickly – 1 month – therefore looking for a tactical solution (calling it MVP to make it sound less desperate).
The chosen technology/product must be future-proof and fit the strategic direction (cannot justify spend on throw away).

6 months later…

  • Why isn’t the first project complete? It was supposed to be quick.
  • Where is the value add from using this technology/product? It is supposed to be the strategic choice for all projects to come.

What has just happened?…

If tactical is aligned with strategic, it would not be called tactical, it would be called strategic.
The strategic choice product/technology may not be able to demonstrate value add for the entire program in a tactical (also the first) project.
The same features and functions for building strategic capabilities rarely, if ever, meet the criteria and constraints of legacy in a tactical build.

Categories
Engineering Hives and Silos

Not Meeting in the Middle

The person holding the P&L and sponsoring the project needs new, improved capabilities for the business to create value. A suitable IT solution and project could deliver the needs.
There is no interest in architecture, performance, documentation, choice of platform. It just needs to happen.

The team of individual contributors in delivery just want to get their code into production as fast as possible. This is particularly true for contractors and offshore delivery centres with economical rates measured on the speed of delivery.
They too have little interest in architecture, performance, documentation, platform.

Folks in the middle who are tasked to make it all sustainable – so the next project does not cost an arm and a leg, and does not take a lifetime to complete – are in an impossible position.
They do care about architecture, performance, documentation, platform, and more.

Many businesses have been practicing decades of waterfall shaped delivery. The projects are typically sized between 6 to 12 months, while parent programs can run much longer. A sizeable work upfront on requirements is rapidly followed by delivering, churning out code up to final delivery into production.
Meanwhile, governance bodies and design authorities are desperately trying to wedge themselves in between stages to provide some oversight and much needed guidance.

Now that everyone and their dog is pitching to be agile, a torrent of anti-patterns emerge from waterfalling into sprints expedited by doing away with plan, design and documentation.
Practically, entirely removing the opportunity for oversight and to work out sustainable solutions.

A worthy read on the struggles of business-IT alignment: Don’t become an Enterprise/IT Architect… by Gerben Wierda

Categories
Engineering Product Management

Measuring Outcome

What is the measure of an outcome in an organisation?
Is it a tick in the box?
Is it a business relevant metric?

Metrics are too often mistaken for a tick in the box.

Metrics are hard, measuring them is even harder.
Moving the needle on a metric that counts is an achievement.
Recognising people, teams, divisions, entire organisations for results is leadership.

A tick in the box has never delivered any real value.
A tick in a box has never transformed a business.
What kind of culture does giving credit for a ticking the box drive?

If your daily work involves ticking boxes, send a link to this article to your superiors.

Categories
Engineering Product Management

On Measuring

Measuring code quality, productivity, technical debt is difficult.

Measuring number of lines of code; speed of delivering code; completed stories, features, epics is easy.

Do not trade quality away for comfort.

Categories
Engineering Product Management

The Obsession with Blockers

So much focus is lost on asking – What are the blockers? – that the organisation forgets to enable its people to do the work.

Failing to enable those that do the work is the biggest blocker in an organisation.

Categories
Engineering

4 Signs Your Business Needs a CTO

If your business involves technology and you find yourself thinking along any of the following…

  1. Let’s get a developer to do “the tech”
  2. Let’s outsource “the tech”
  3. Let’s get some software off the shelf for “the tech”
  4. Let’s get started and sort out “the tech” once we start growing

…then it is a sign that you should think about having a your business might need a CTO.

Whatever can go wrong, will go wrong

Murphy

Let’s see what can go wrong with each of the four points.

The Technical Talent

Good technical people in your network that you can rely on is the best thing to have for your business. Otherwise, finding technical talent can be exciting if “looking for co-founder speed-dating” is your thing.
Your next best option is to get guidance from a technical lead who has been there, done that; and will

  • help making early technology decisions that fits your bill;
  • align product features or project scope with schedule and budget.

The Outsourcing Shop

Getting somebody external to build your tech – outsourcing – is a frequently favoured approach. It promises to deliver a bespoke solution, tailored to your needs, often advertised at a low cost. If you have not worked with outsourcing companies before, or if you have not managed product development with a partner before, this could be a bumpy and costly ride.
Delivering a successful project with external partners requires a great deal of preparation and dedication during the execution from your side, including

  • interview, evaluate and select partners, suppliers;
  • oversee delivery from start to finish.

The Off-the-shelf Product

Finding a suitable and affordable off the shelf product, commercial or free open source, is a great way to get started. If you have the luxury of choice, then a thorough, objective analysis of options should reveal the most fitting one.
A single package rarely meets all needs. A new set of challenges will rise from customising it, or from integrating it with additional solutions.
Circumstances could lead to considering building your own tech. It is a decision not to be taken lightly.
Mitigate the risks by getting help for

  • vendor and product selection;
  • buy versus build analysis.

The Postponed Tech

Kicking the tech decision tin can down the proverbial road tends to build up technology debt. It risks future development, innovation and growth by increasing cost, timeline and limiting scope.
Think about tech strategically, make it part of your roadmap to address technology debt.
Addressing tech at the growth stage will throw up more of the same issues described earlier with the added twist of dealing with legacy.
Avoid being limited by tech at this stage by

  • devising strategy and roadmapping early;
  • performing regular technology audits.

Making technology work to create value for your business is often not a trivial task. The runaway costs, scope creeps, schedule overruns together with unnecessary complications and complexity can be overwhelming.

If still not convinced, or cannot commit to getting a CTO on board, perhaps consider working with an interim or part-time CTO.

Early stage technology decisions will have a profound impact on your business for a long time.

Categories
Engineering Product Management

The Choices We Make…

Imagine…

You are a techie in a corporate.
The platform you are working on offers a vast range of tools and capabilities.
You find the next task/user story/requirement to work on.
You immediately think of a way to implement a solution to complete the task and tick the box.

You have choices…

  • Are you going to discuss alternative implementations with your team
  • Are you going to check if this implementation has been done somewhere else?
  • Are you going to review against the existing design standards and patterns?

OR

  • Are you going to get it done as soon as you can to show high productivity on the dashboard?

If you are an individual contributor, your choices will be limited.

If you are managing a team, then and ask yourself – What can I do to foster the former behaviour over the latter?

Either way, if you feel conflicted about this and prefer to have you and your team showing high productivity on some dashboard, then send a link to this article to your superiors.