Hello, everyone! This is Andrew Putin. Today we’ll talk about the most frequent inquiry from the managers: “where to get a Senior developer” or “a Chief Architect” or “CTO” or some other kind of a highly super-competent IT-specialist.
Sometimes, this issue occurs only after the previous chief architect has quit. Why does this happen, and why is it dangerous to keep on hiring one superman after another. Let’s discuss this issue in this video.
First of all, I want to say that with this video I am not trying to belittle the experience of a technical expert. An engineer, especially an experienced one, is always very valuable. I am talking about something else here - about the magical thinking of top managers, who try to solve management problems at the expense of engineers.
So, you are faced with the fact that your key employee has left the company and you need another one. First, let's understand why the employee has become "key"?
Ron Hubbard suggested in enterprise organization charts that the person in charge of the rules (the qualifications division) and the person who works by the rules (the technology division) are different divisions. The qualifications department is responsible for continuous quality improvement through rules, standards, regular audits, and training courses. The software developers in the technology department have to rely on these standards, they can jointly adjust the standards, but they rely on those standards. Transferring to IT, here we should say that the main task of the qualification department is to make sure that the software architecture is simple, unambiguous, and loosely coupled (I talk about this in the video about SOA).
And if you have these functions really separated and these business processes are executed, then neither the loss of a qualification department specialist, nor an engineer in technology leads to a breakdown of your processes and knowledge of them.
This separation moves the rules from heads to some documents, the architecture of your IT is then not in the head of a particular IT Ironman. In this ideal picture of the world, any developer can figure something out and fit into the work. Moreover, your architect in such a case may not be an IT specialist at all, because if the SOA and DDD principles are followed, the program architecture and the business architecture do not differ.
But this is not usually the case. A common situation is that before a disaster, the business does not follow the right separation of areas of responsibility. A monolith is created, either explicitly or virtually. For example, your company has one big application - like an ERP or CRM system. Since this big program has the interests of many executives, there's lots and lots of functionality. One is connected to the another in a complex and often implicit way. It is not easy to keep such a picture inside the head of one IT specialist, and the one who succeeds becomes your irreplaceable superhero.
It also happens when your company's product is such a monolith. For example, you develop a CRM system for bakers, and everything inside is blended indiscriminately. Customers, requests, business processes, communications mechanisms. There are also a lot of point-to-point integrations, which I talk about in detail in our other videos about buses - see a link on it in the description below.
Other times, you have a virtual monolith. That is, on the surface you have a lot of different services, or even your developers have declared that you have a microservice architecture, but in reality the way they are connected to the business and to each other is hard even for developers to understand. The situation is even worse when you have a million fancy solutions - which means that the engineer studied these solutions at your expense, but it had no effect.
What do all these cases have in common?
A pile of code whose architecture would break even Einstein's head. The team on such projects burns out in a couple of years - because the technical team needs to make a large flow of changes to various managers, and the product is so complex that it has already become unsupportable.
In the "effort-to-functionality" chart, such a project has come to a critical line - right here.
Your engineer lacks the business education to see the errors of organizational design, and attempts to solve organizational problems with code are a fruitless waste of near-ending energy.
If you don't build business processes and divide responsibility for IT products to the appropriate department heads, don't address aspects of proper communication between different products and don't build processes that control all of this, the application and IT loop architecture is built in a different way than your enterprise domains. I talk more about this in the video about service-oriented architecture. I'll also note here that developers are usually technophiles. Those who believe in the power of technology without regard to the realities of business and organizational structure. Developers cannot take responsibility for delegating authority across departments, and management has stepped away from these decisions in the hope that it will somehow take care of itself. As a result, developers end up with a virtual or true monolith. The business keeps demanding change, and your superhero realizes that he's doing more and getting less done. This leaves the specialist depressed and dissatisfied with his or her job.
Firing your professional is the only way to go, even if he doesn't want to leave.
The more expert the engineer, the more willing he is to try different things in your landscape - after all, you don't define areas of responsibility, and therefore who is responsible.
The more talented such an expert is, the more difficult it will be inside your already difficult solution. For example, who on the side of the business is responsible for a huge ERP, if it includes both sales and HR and accounting departments? The accountant? The sales department? The CEO? Usually the responsible one is the superhero - the technical director or chief architect, who begins to determine what is a priority and what is not. Business hopes for the right architecture, not realizing that the right architecture should be determined by business, not by technicians. And since it is, don't be offended.
So if you want to hire a signor, check yourself - isn't that just delegating key decisions to a techie. He's a programmer, isn't he supposed to know how to fix long overdue problems with a swipe of the keyboard? The Matrix programmer got in and changed walls and physical objects by typing something on a keyboard at 300 characters per minute - but that's in the movies. In life, you're better off starting from the principle that you don't need a superhero, but an ordinary developer with whom you will fix organizational and technical errors. You will solve problems organizationally, he will implement simple functions.
If you are looking for a miracle worker, you will find either a storyteller or you will find another superhero who will start working for you until he, also, burns out. And the wheel of Sansara will take another turn. Until it burns out for you.
We are sure that the beauty of architecture is in its simplicity. The only paradox is that it's not easy to do simple. Goodbye, everyone.