It’s been one year since I have re-joined the corporate IT industry, where I started my IT career. When you come back to a big corporate after 7 years in a small start-up, you look differently at a lot of things, and you see things that you did not notice previously. (see the wet monkey theory)
One of the biggest assets in a big corporate, is its’ access to people and resources, but it is also its’ biggest weakness.
When you are working in a small start-up, you are forced to do creative problem solving. There are no other options.
Sometimes, in the big corporate companies, it’s just easier to throw money and/or people at the problem. Even when we want the company to be more innovative and creative, we create a team that is responsible for that. Now I am not saying that that team can not be innovative, I am just saying that in a small company innovation and creativity comes naturally.
This very long blog post is my thoughts on how we can potentially solve this in bigger companies. Allow big companies to be big, but also as agile and movable as a small start-up.
I only suggest to change one thing, but that thing sits at the core of a company…
Organizational structure
What do you need to create a system ? (that can enable a business)
Some tools ? Yes maybe.
A server ? Of course.
A Professional responsible software engineer ? Aaa ! Yes. That is actually all that you need. That is the guy that can create a system. And the code is the only tangible artifact that you actually need. All the other outputs purely exist to enable the code to be correct. The software engineer will (and should) decide what tools he needs.
All you (really) need is a software engineer.
That is why small companies sometimes only have one or two software engineer. They do not have Business Analysts, and Testers and Deployment managers etc.
Just the software engineer.
It’s not that a business analyst, tester etc is not important. In fact, the part they play in creating good software is very important, but the bottom line is that they are all just roles. Roles or functions that all good software engineer should be able to perform. And all good software engineer can actually perform these roles, they need to be able to do this in order to be good at their profession.
Growth
So when a company grows, as a way to scale, they start to assign specific roles to specific people. Some roles can actually be performed by people that can not write software. This is a valid and workable way to scale. Now the professional software engineer can focus on the writing of the code (The actual only thing we need at the end) and other people start taking care of certain roles.
This approach is not at all unique to the IT industry. Most professions work this way.
A doctor, doing mission work at a war torn county, might be in a situation where he/she is the only medical professional.
The doctor will fulfill all the roles needed to get the job done. He/she will be the doctor, nurse, receptionist, cleaner …etc. But back at home, he/she might be working in a hospital with other doctors and nurses and specialist etc. When the doctor operates, these other peoples’ sole purpose is to assist him to do the best job he can. Similar examples can be drawn from any other professional job like architects or engineers or lawyers.
Software engineers are by no means medical doctors, for sure, but a lot has been written and done to try and make IT into a professional industry. Personally, I think that will be too hard to manage. The IT industry is too big and specialized to actually create one professional body. But maybe we are focusing on the wrong thing? Rather than wanting to create a professional body that certifies software engineers as professionals, should we not focus on changing the way we work to align ourselves with the rest of the professionals?
If your company is small, you kind of work that way by default. But as the company grows, the roles become people, the people become teams, the teams become ‘centers of excellence’.
This might make sense on paper - lets centralize all business analysts in the company into one big team. Project teams can then draw resources from this pool when doing a project… simple. Similar process with the developers, testers and architects. Lets also centralize Operations and the guys looking after the servers and doing the deployments.
The problem with this is, that the role that used to exist, purely to support the software engineer, is now very far removed from that developer. The role has morphed into a big team, it has taken on a life of its own, and it does not add any value to the developer anymore. In fact, there is a point in this growth, where it actually becomes harder for the software engineer to perform certain tasks because of this role-based team. You might also find that grouping roles together, to create centers of excellence might lead to centers of mediocrity.
The big mistake
In my humble opinion, the biggest mistake that our industry made, was to create an operating model based on the building industry (see Uncle Bob’s Foundations of the SOLID principles). Sure, one builds buildings and the other builds systems. So both build stuff, but creating software is not at all similar to building a house.
A lot has been written in this regard as well. For me the biggest issue with drawing this parallel is that we now treat the software engineer like a brick layer.
This is sometimes very visible in bigger companies where we scale up “brick layers” to get a job done quicker (see Brooks law).
We need to change this. Instead of treating the software engineer as a brick layer, rather treat him/her as the doctor/professional - and then recruit accordingly. Once you have the qualified, responsible software engineer, allow this professional to create the team he/she needs to do the job. Allow them to define the processes and tools needed to do the job optimally.
Centralizing teams
Do not centralize a team around a role or technical concern.
(I repeat: Do not centralize a team around a role or technical concern)
If your business is growing and you get more and more people, steer away from grouping roles together.
Teams should be created around business concerns, not technical concerns.
Teams should be lead by the most senior software engineer (the professional).
Roles should purely exist to enable the software engineer(s) to create great, clean systems.
Tools should purely exist to enable the software engineer(s) to create great, clean systems.
Processes should purely exist to enable the software engineer(s) to create great, clean systems.
Don’t lose sight of the above as your company grows.
Guerrilla warfare
“Guerrilla warfare is a form of irregular warfare in which a small group of combatants such as armed civilians or irregulars use military tactics including ambushes, sabotage, raids, petty warfare, hit-and-run tactics, and mobility to fight a larger and less-mobile traditional military.” - from https://en.wikipedia.org/wiki/Guerrilla_warfare
A big company is like a big ship. It does not change direction easily. We have all heard that before. And for some reason that is enough reason for us to then just go about our normal way of work.
If a small company can move quickly, then a big company with more resources and more money should also be able to. We should stop accepting “Well that is just how things work in a big corporate”!
How do you solve any problem ? (And all software engineers say….)
You break it up into smaller pieces (Divide &conquer). And that is how you should solve the big ship that can not move problem.
Break it up into smaller pieces. Very similar to Guerrilla warfare. Lets call it Guerrilla programming. Any big company will be able to change direction easily, if they manage to change their organizational structure to small teams around business concerns.
The focus should be on changing your organisational structure. Do not create virtual project teams that group together for the duration of a project. Your teams should be cross-functional teams with cross-functional people and their sole purpose to support the creation of clean, brilliant software!
Value
It’s all about value. As soon as your organizational structure makes it difficult for project team members to deliver on a deadline, you know that your structure is no longer adding value.
Or let me rephrase.
As soon as it’s easier for the software engineer to just do the task needed him/her self, than to get another role-team to do it, the role-team is not adding value anymore.
This seems to be a very common problem when your teams are structured by role rather than by business concern.
Communication
Structuring your teams by role also add immense communication overhead. This in turn then contributes to the slow delivery of projects, and to the reason that the ship can not turn. Sure, creating teams as business concerns will also need communication, but that communication is much more natural as it represents your business.
Blame
Another very common symptom in a company that is structured by role/technical concern, is a culture of blame or finger pointing. As soon as the pressure starts, role-teams start pointing fingers at each other and the project cost starts sky rocketing. Team X tries to tell team Y how to do their role, Team Y decided to just do team Z’s responsibility themselves, because of bad delivery. I have never seen a company that is structured by role that just works.
Now maybe you think that this structure will work if you just work harder and communicate better… the point is that your organisational structure should assist teams to deliver. It should not only work with a lot of effort, it should come naturally. We have more than enough other challenges when it comes to delivering good software. An organisational structure that makes it harder to deliver is the reason the ship can not turn.
Agile development
“Agile software development is a group of software development methods in which requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development, early delivery, continuous improvement, and encourages rapid and flexible response to change.”
By definition, agile development can only really work if your organisation is structured around business concerns (self-organizing, cross-functional teams). Implementing agile when your organisational structure is wrong might mean you miss out on a very important part of agile - cross-functional! And all you end up doing is having costly stand-up meetings with all your developers.
Test driven development
“Test-driven development (TDD) is a software development process that relies on the repetition of a very short development cycle: first the developer writes an (initially failing) automated test case that defines a desired improvement or new function, then produces the minimum amount of code to pass that test, and finally refactors the new code to acceptable standards”
TDD is just a way to solve the problem of a structure where the software engineer is far removed from the testing team, and the testing team (NOTE: not the tester) is not adding value. The role of testing is now done with automated, repeatable test cases.
DevOps
“DevOps is a software development method that stresses communication, collaboration, integration, automation, and measurement of cooperation between software developers and other information-technology (IT) professionals.”
Again, by definition, if you want to make it very easy to enable DevOps, you will have to change your organisational structure to facilitate that. Ops is just a role, and big parts of that role can be automated.
Agile development, TTD and DevOps is just a way to solve the value problem of a structure where the software engineer is far removed from the role. Some roles can be replaced by automation, some by bringing the role back closer to the developer. The whole industry is moving towards this model, and it’s time that big companies start organizing their delivery teams to enable it.
Microservices
“In computing, microservices is a software architecture style, in which complex applications are composed of small, independent processes communicating with each other using language-agnostic APIs. These services are small, highly decoupled and focus on doing a small task.”
From a enterprise level, Microservice fits this operating model like a glove. You can now broaden your standardization of tools, processes language etc. This also widens your resource pool. Now you do not have to hire (for example) IBM Java developers, you can find the best software engineers the industry has to offer, allow them to run their “Guerrilla Team” using any major language and tools and processes. Standardize only on the way in which we publish our use cases for other Guerrilla Teams to consume.
If your Guerrilla Teams are small enough, it also allows you to experiment with new technologies on smaller use cases. The risk that a certain technology might fail is less as the deliverable is much smaller and easy to be replaced.
Shared business services
Centralizing teams around a business concern does not always mean that the business-concern-consumer is your end client. The consumers might sometimes be other teams within your company.
This means your consumers might be other software engineers. Theses are the most difficult consumers to have!
Example: A team that looks after the Client data, or a team that allows you to communicate to the client. These teams needs to be run like they provide a cloud service on the Internet to any software engineer. If your communication team does not make it as easy as a mailchimp to send notifications, you need to ask yourself why are we not using mailchimp?
These teams need to pass the “10 minutes test”. If you are a small company, the “10 minute test” is what you have to use in order to make a decision on which service to use - there is no time or money for months and months of POC’s.
The service that you could get working within 10 minutes, is the one you use.
As long as you consume these services in a pluggable way, you can always change later (you rarely do).
So these shared services need to know that their main consumers are developers, and they need to be “developer friendly”. It should be easier for another guerilla team to use their service, than to write the software themselves.
Shared technical services
Even though I warned against centralizing teams around technical concerns (and then repeated it), you might still want to do that. If you do, these technical teams need to be treated like the shared business services teams. Their main consumers are other guerrilla teams, and they need to also pass the 10 minute test. They need to add value to the software engineer..
If your team that provide hosting can not provide the same ease of use than a rackspace or even better a jelastic, why would a guerrilla team want to use them?
If these teams purely exist because of a top-down company mandate, they really are very similar to a government funded company that should provide electricity to consumers and have a monopoly. You will eventually have blackouts as there is no incentive for this company to provide good services.
If you create an organizational structure as proposed in this blog, you might find that these shared technical services evolve naturally. Small Guerrilla Teams need these services and create them for themselves, and later find that other teams can use them, so they split off to create a new small team that do just that. Keep them small and it might work.
Both shared technical services and shared business services are (what I call) enabling teams. The enable the delivery teams.
Channels
Sometimes, in big companies, you will find business teams that are grouped around a technical concern. (I ‘m not sure why this happens, but I assume it’s again a problem that was solved by throwing people at it)
So you might have a different business unit that look after the same product offering, purely because of the way in which you deliver this to your client.
This is not only bad for the customer (your client), but also bad for your IT.
For a client there is no such thing as a channel. For example, if I have product X with your company, whether I call the call center, visit your website or use your app, for me, your client, it’s the same thing. Why is it not for you?
Technical concerns should be the problem of the technical teams. If you have a product that needs to be on multiple channels, then the same business unit should define these requirements.
If you want to centralize all your companies’ offerings into one channel, and you want to centralize an IT team around a channel, this team needs to make it easier for the Guerrilla teams to get their use cases in the channel, they should not write the software themselves (see Shared technical services).
These teams should really create and maintain a platform that enables software engineers to publish to a certain channel.
Implementation
Let’s say you agree with my ramblings, how do you implement this? It’s fine if your company is growing, as you can let it grow naturally into this structure. But what if you are already a big corporate?
I don’t have the answers, but what I can say is: Don’t make plans that will take years to implement.
Rip of the plaster.
Get it done.
Start a Revolution!