cft

CIOs: 3 Steps to Speed Up Your Time-to-Market And Avoid Fights With Business units.

Working with large organizations for the past 10 years made me think about my native country


user

Maxime Topolov

3 years ago | 4 min read

Barony, political fights, slow decision cycles, and waste.

But more importantly, there is always the same black-sheep to blame: the IT department.

They are the source of all evils. Late projects, ever-growing budgets, slow time-to-market, complicated jargon (what the fuck is a GraphQL microservice ?!), security rules (why n00b isn’t a good password ?).

Of course, they are not.

There is a lot of literature on how to overcome organizational frictions between departments and ways to introduce agility in teams. Most of them are related to team organization, objectives, processes, and methods.

Let’s see how some simple architectural and organizational decisions may lead to tremendous results. Oh and you will probably need a platform that helps you implement it, we’ve built it :) Check out: https://code.store

1. Switch to micro-mini-macro-services.

Working on large monoliths slows you. You accumulate technical debt, your struggle with team velocity, support & maintenance costs are higher than Snoop Dogg.

You need to switch progressively to a micro/mini-services architecture. Why?

  • It will be easy to organize your development teams (see next chapter)
  • You can decide on each service to keep it inhouse or outsource it.
  • You can replace each service with a SAAS solution, adopting a best-of-breed strategy
  • You limit your technical debt
  • You can have different technologies running different services, therefore hire easily
  • You can re-use running services in different front-end applications
  • You can implement new features way faster, as they concern small code-bases updates or entirely new services.

2. Small autonomous, agile, and cross-functional teams.

Conway’s Law, which states that organizations that design systems “are constrained to produce designs which are copies of the communication structures of these organizations.”

You can relate Conway’s Law to fractal theory, chaos theory, or other theories about organizational structures. But the implications for software development are not complicated: The structure of your software is likely to reflect the structure of your software development organization.

That means the second important move is to re-organize your IT department and assign for each mini-service an independent, cross-functional team.

Cross-functional teams may fail because the organization lacks a systemic approach. Teams are hurt by unclear governance, by a lack of accountability, by goals that lack specificity, and by organizations’ failure to prioritize the success of cross-functional projects.

Take care of the alignment of teams with objectives of business structures they represent.

Oh, and don’t worry about large, long term global projects, you still can have horizontal, department-large guilds, but they are always secondary to the core, business-oriented, accountable teams.

The best path to clear accountability is to empower small teams that own something end-to-end, which in this example is a mini/macro/micro-service. A service does one thing and one thing well, a concept based on Robert (Uncle Bob) Martin’s single responsibility principle. Whether you call it a microservice or not doesn’t really matter, what matter is that your teams are :

  • Independent: because each service does not depend on any other, you can give your team full freedom on the way they work. It will enhance their velocity and motivation. Treat them like a small startup.
  • Cross-functional: you want independent service teams, that are fully accountable for the service they’re building and maintaining. They need all resources they would need to build it: business analyst/product owner, SCRUM master, developers, DevOps, test engineers, DBA…
  • Agile: they should work in using classical SCRUM. You want them quickly iterate as demand from service consumers will arrive.
  • Accountable: They build, run, and support their service. They hire people they need and manage their P&L. They are accountable for the quality of their support, budgets, and timelines.
  • Competitive: As each team works only on a small portion of your global software assets, their internal clients may switch them for a SAAS vendor if their in-house built solution is not competitive enough in terms of quality or costs.

3. Put a price on usage, not time.

How big should be my service? What feature should I add? Your internal clients complaining about the quality of your support? SLAs? Lack of agility?

Make the internal clients pay per usage for each of your API endpoints rather than for time spent to build them.

The ubiquitous language of money will magically make everyone aligned and perfectly understand the impacts of every decision they make.

Performance budgets are very useful in subjects where multiple stakeholders have opposite objectives. Let’s try on mini-services too.

Putting a price on usage forces your service teams and their internal clients to negotiate and think in a pragmatic way:

  • Do I really need a new developer in my team based on the current pace of new features and support requests? The team is small, and problems are easy to grasp, they can be fully autonomous in their recruitment.
  • What is really important to my internal clients? If they do not understand the value of a service, maybe it should not be an independent service?
  • How should I optimize hosting to include its costs in pay-as-you-go price?
  • It forces you to isolate your services and limit inter-services communication otherwise you’ll have to integrate those calls inside your pricing.
  • It’s a very good way to decide when to outsource a service or not when to buy it externally (you can easily compare, as most of SAAS software provide metered, usage-based pricing)
  • Reusability: if there is only one client paying for a service, no reason to make any efforts to make it generic. Does a new one come-in with some change requests? You can easily see if there are any ROI to create a new service, fork the existing one, or modify it, adding new features (paid by the fact this service will be used twice now).
  • It forces you to document, explain, sell your service. It must work and be supported (or you pay penalties) or abandoned altogether.
  • It opens a door for new revenues and business models for your company (If a service is valuable for your internal clients, it might be for people outside your company too).
  • Finally, it encourages your teams to work in a start-up like the state of mind.

Switching to microservices, agile independent teams, and usage-based pricing will help. And you have a platform that could help: https://code.store


Upvote


user
Created by

Maxime Topolov


people
Post

Upvote

Downvote

Comment

Bookmark

Share


Related Articles