Tim Lister - Co-author of books

• "Human factor. Successful projects and teams "(the original book is called" Peopleware ")
• “Waltzing with the Bears: Risk Management in Software Development Projects”
• “Amazing with adrenaline and zombie patterns. Project Team Behavior Patterns

All of these books are classics in their field and are written with colleagues from the Atlantic Systems Guild . In Russia, his colleagues are most famous - Tom Demarco and Peter Khrushchka , who also wrote many famous works.

Tim has 40 years of experience in software development, in 1975 (no one who wrote this hubpost was born this year), Tim was already Executive Vice President of Yourdon Inc. Now he is engaged in consulting, training and writing, from time to time attending conferences around the world with reports .

Especially for Habr, we did an interview with Tim Lister. He will open the DevOops 2019 conference, and we have accumulated a lot of questions, about books and more. Interviews are conducted by Mikhail Druzhinin and Oleg Chirukhin from the conference program committee.

Michael: Could you say a few words about what you are doing now?

Tim: I’m the head of Atlantic Systems Guild. There are six of us in the Guild, we call ourselves principals. Three in the USA and three in Europe - that's why the Guild is called the Atlantic. We have been together for so many years that you just won’t count. We all have our own specialties. The last decade, or even more, I have been working with clients. My projects include not only management, but also the setting of requirements, project planning, and evaluation. It seems that projects that start poorly usually end poorly. Therefore, you should make sure that all activities are really well thought out and agreed that the ideas of the creators are combined. It is worth considering what you are doing and why. What strategies to use to complete the project.

For many years I have been advising clients in a variety of ways. An interesting example is a company that makes robots for surgery on the knee and hip joints. The surgeon does not operate completely independently, but uses a robot. Security here, frankly, is important. But when you try to discuss requirements with people who are focused on solving problems ... It sounds strange, but in the USA there is the FDA (Federal Drug Administration), which licenses products like these robots. Before you sell and use something on living people, you need to get a license. One of the conditions is to show your requirements, what the tests are, how you tested them, what the test results are. If you change the requirements, then you need to re-go through this whole huge testing process again and again. Our clients managed to include visual design of applications in their requirements. They took screenshots directly as part of the requirements. We have to pull them out and explain that for the most part all these programs do not know anything about the knees and hips, all these things with the camera, etc. We need to rewrite the documents with the requirements so that they never change, unless some really important fundamental conditions change. If there is no visual design in the requirements, updating the product will be much faster. Our job is to find those elements that deal with operations on the knee, hips, back, pull them into separate documents and say that they will be fundamental requirements. Let's make an isolated group of requirements about knee surgery. This will build a more robust set of requirements. We will talk about the entire product line, and not about specific instances of robots.

A lot of work was done, but they nevertheless got to the places where they had previously spent weeks and months of repeated tests without meaning and necessity, because their requirements, described on paper, did not coincide with the real requirements on which the systems were built. Each time the FDA told them: your requirements have changed, now you need to check everything from scratch. Full cross-checks of the entire product killed the company.

So, there are such wonderful tasks when you find yourself at the very beginning of something interesting, and the very first actions set further rules of the game. If you do so both from a managerial and from a technical point of view, this early activity will start to work well, there is a chance at the exit to get an excellent project. But if this part went off the rails and went somewhere wrong, if you can’t find the fundamental agreements ... no, not that your project will necessarily fail. But you will not be able to say: "We are well done, we have done everything really effectively." These are the things I do, communicating with clients.

Michael: That is, you launch projects, do some kind of kickoff and check that the rails lead in the right direction?

Tim: We also have ideas on how to put together all the pieces of the mosaic: what skills we need, when exactly they are needed, what the core of the team looks like and other such fundamental things. Do we need full-time employees or can we recruit someone part-time. Planning, management. Questions like: what is most important for this particular project? How to achieve this? What do we know about this product or project, what are the risks and where is the unknown, how are we going to deal with all this? Of course, someone at this moment starts shouting “But what about agile ?!”. Well, you're all flexible, but so what? What exactly does the project look like, how are you going to take it out so that it fits the project? You can’t just say that “our approach is pulled by anything, we are a scrum team!” This is nonsense and nonsense. Where are you going to go next, why should it earn, where is the point? I teach my clients to reflect on all these issues.

19 years of ajail

Mikhail: In Ajail, people often try not to determine anything in advance, and make decisions as late as possible, saying: we are too big, I will not think about the general architecture. I will not think about a bunch of other things, instead, right now I will supply the customer with something working.

Tim: I think agile methodologies, starting with Agile Manifesto in 2001, have opened the industry's eyes. But, on the other hand, nothing is perfect. I am entirely on the side of iterative development. Iterations make a lot of sense in most projects. But you need to think about the question: after the product came out and began to be used, how long does it live? Is this a product that will last six months, and then it will be replaced by another? Or is it such a product that will work for many, many years? Of course, I will not name names, but ... In New York and its community of financiers, the most fundamental systems are very old. It is amazing. You look at them and think that you would go back in time, in 1994, and tell the developers: “I came from the future, from 2019. Just design this system as much as you need. Make it extensible, think over architecture. It will then be improved for more than twenty-five years. If you delay the development a little longer - no one will notice this on a scale of history! ” When you evaluate things in the long run, you need to consider how much it will cost in its entirety. Sometimes a well-designed architecture is really worth it, and sometimes not. You need to look around and ask yourself the question: are we in a suitable situation for such a solution?

So an idea like “We are for agile, the customer himself will tell us what he wants to receive” - it is supernative. After all, customers do not even know what they want, and even more so they do not know what they could get. Some will begin to cite historical examples as arguments, I have already seen this. But technically advanced people do not usually say that. They say: “Now is the year 2019, we have such opportunities, and we can completely change our view of such things!” Instead of mimicking the existing solutions, making them a little more beautiful and combed, sometimes you need to go out and say: “Let's completely reinvent what we are trying to do here!”

And I do not think that most customers can think of a problem in this way. They see only what they already have, and that’s it. Then they come with requests like “let's make it a little easier,” or whatever they usually say. But we are not waiters and waitresses to take an order no matter how stupid it turned out, and then bake it in the kitchen. We are their guides. We must open their eyes and say: hey, here we have new opportunities! Do you realize that we can really change how this part of your business is done? One of the problems of adjayl is that he moves away from the realization of what is an opportunity, what is a problem, what do we need to do, which of the available technologies are best suited in this particular situation.

Perhaps I went too far with skepticism: a lot of wonderful things are happening in the agile community. But I have a problem with the fact that instead of defining a project, people start to shrug. I would ask here - what are we doing, how are we going to do this? And in some magical way it always turns out that this client should know better than anyone. But the client knows best of all only when he chooses from things already built by someone. If I want to buy a car and I know the size of the family budget, then I will quickly pick up a car that suits my lifestyle. Here I know everything better than anyone! But, please, notice that someone already made the machine. How to invent a new car, I have no idea, I'm not an expert. When we create custom or some special products, the customer’s voice must be taken into account, but this is not the only voice.

Oleg: You mentioned Agile Manifesto. Do we need to somehow update or revise it taking into account the current understanding of the issue?

Tim: I would not touch him. I think this is a great historical document. I mean, he is what he is. He is 19 years old, he is old, but at one time he made a revolution. What he did well was to launch a reaction, they began to whisper about him. Most likely, you did not work in the industry in 2001, but then all worked on processes. Software Engineering Institute, Five Levels of the Software Integrity Capabilities Model (CMMI). I don’t know if such legends of antiquity tell you something deep, but then it was a breakthrough. At first, people believed that if the processes were built correctly, then the problems themselves would evaporate. And then the Manifesto appears and says: "No, no, no - we will be based on people, not on processes." We are masters of software development. We understand that the ideal process is a mirage, it doesn’t. There is too much idiosyncrasy in projects; the idea of ​​a single, flawless process for all projects makes no sense. The problems are too complex to claim that a single solution has been found for everything (hi, nirvana).

I do not presume to look into the future, but I will say that people have now begun to think more about projects. I think that Agile Manifesto is very good, he leaps forward and says: “Hey! You are on a ship, and you yourself are leading this ship. You will have to make a decision - we will not prompt a universal recipe for all situations. You are the crew of the ship, and if you are good enough, you can find the path to the goal. There were other ships before you, and other ships will be after you, but nevertheless, in a sense, your journey is unique. ” Something like that! This is a way to think. For me, nothing is new under the moon, people have sailed earlier and will swim again, but for you this is your main trip, and I will not tell you exactly what will happen to you. You must have the skills of coordinated teamwork, and if they really are, everything will work out and you will come where you want.

Peopleware: 30 years later

Oleg: Peopleware was also a revolution, like the Manifesto?

Tim: Peopleware ... Tom and I wrote this book, but did not think that everything would happen. Somehow, it resonated with the ideas of many people. This was the first book that said: software development is a very human-intensive activity. Despite our technical nature, we are also a community of people building something big, even huge, very complex. No one can create such things alone, right? So the idea of ​​a “team” has become very important. And not only from the point of view of management, but also for people of a technical warehouse who came together to solve really complex deep problems with a bunch of unknowns. For me personally, throughout my career this has been a huge test of intelligence. And here you need to be able to say: yes, this problem is more than I can handle it myself, but together we can find an elegant solution that we can be proud of. And I think that this particular idea resonated the most. The idea that we work part of the time on our own, part of the group, and often the decision is made by the group. Group problem solving quickly became an important feature of complex projects.

Despite the fact that Tim had a huge number of reports, there are very few of them posted on YouTube. You can see the 2007 The Return of Peopleware report. Quality, of course, leaves much to be desired.

Michael: Has anything changed in the last 30 years since the release of the book?

Tim: You can look at it from many different angles. Speaking sociologically ... once, in simpler times, you and the team were in the same office. You could be there every day, drink coffee together and discuss work. What really changed is that now teams can be distributed geographically, in different countries and time zones, but nevertheless they are working on the same task, and this adds a whole new layer of complexity. It may sound old-fashioned, but there is nothing better than face-to-face communication, when you all come together, work together, you can go to a colleague and say: look, I found how you feel about it? Face-to-face conversations provide a quick way to move towards informal communication, and I think this should appeal to adjayl lovers too. And I’m worried because in reality the world turned out to be very small, and now it is all covered by distributed teams, and all this is very complicated.

We all live in DevOps

Michael: Even from the point of view of the conference program committee, we have people in California, in New York, Europe, Russia ... in Singapore there is still no one. The difference in geography is quite large, and people begin to be distributed even more. If we are talking about development, can you tell us more about devoops and the destruction of obstacles between teams? There is a concept that everyone is sitting in their bunkers, and now the bunkers are crumbling, how do you like this analogy?

Tim: It seems to me, in the light of recent technological breakthroughs, devops is of great importance. Previously, you had teams of developers and admins, they worked, worked, worked, and at some point a thing appeared with which you could come to the admins and roll it out to the prod. And here the conversation about the bunker began, because the admins are like allies, not enemies, at least, but you only talked to them when everything was ready to go on sale. You went to them with something and said: look, what is our application, but could you roll this application out? And now the whole delivery concept has changed for the better. I mean, the idea came up that you can push change quickly. We can update products on the fly. I always smile when a Firefox pops up on my laptop and says: hey, we’ve updated your Firefox in the background, and as soon as you have a minute, could you click here and we will give you a fresh release. And I’m like: “Oh yes, baby!” While I was sleeping, they were working right on my computer to deliver me a new release. This is wonderful, incredible.

But here is the difficulty: you have this feature with software updates, but integrating people is much more difficult. What I want to say on the DevOops keynote is that we now have far more players than ever before. If you just think about everyone who takes part in the work of just one team .... You thought of it as a team, and it is much more than just a team of programmers. These are testers, project managers, and a bunch of other people. And everyone has their own views on the world. Product managers are completely different from project managers. Admins have their own tasks. It becomes a rather difficult problem to coordinate all the participants, so as to continue to be aware of what is happening and not to get off the coils. It is necessary to separate the tasks of the group and the tasks relating to all. This is a very difficult task. On the other hand, I think all this has become much better than once many years ago. This is exactly the road on which people grow and learn to behave correctly. When you are engaged in integration, you understand that there should not be any underground development, so that at the very last moment the software does not crawl out of the box: like, look what we did here! The idea is that you can do integration and development, and at the end you'll roll out in a neat and iterative way. All this is of great importance to me. This makes it possible to create more value for users of the system and for your client.

Michael: The whole idea of ​​Devopse is to deliver meaningful work as early as possible. I see that the world began to accelerate more and more. How to adapt to such accelerations? Ten years ago, this was not!

Tim: Of course, everyone wants more and more functionality. No need to move, just pile on more. Sometimes you even have to slow down so that the next incremental update brings at least something useful - and this is completely normal.

The idea that you need to run-run-run is not the best. It is unlikely that anyone wants to live this way. I would like the rhythm of deliveries to set the own rhythm of the project. If you just produce a stream of small, relatively meaningless things, all this in total does not make sense. Instead of thoughtlessly trying to release things as early as possible, what is worth discussing with leading developers and product and project managers is the strategy. Does this even make sense?

Patterns and antipatterns

Oleg: You usually talk about patterns and antipatterns, and this is the difference between the life and death of projects. And now, devops breaks into our lives. Does he have any of his own patterns and antipatterns that can kill the project on the spot?

Tim: Patterns and antipatterns occur all the time. What to talk about. Well, there is a thing that we call "shiny things." People really, really like new technologies. They are simply bewitched by the brilliance of everything that looks cool and stylish, and stop asking questions: is it even necessary? What are we going to achieve? Is this thing reliable, does it make any sense? I often see people, let's say, at the forefront of technology. They are mesmerized by what is happening in the world. But if you take a closer look, what good they are doing - often, there is simply nothing useful!

We were just discussing with our comrades that this year is a jubilee, fifty years since people landed on the moon. It was in 1969. The technology that helped people get there was not even the technology of 1969, but rather 1960 or 62, because NASA wanted to use only what had good evidence of reliability. And now you look at it and understand - yes, and indeed they were true! Now no, no, but you get stuck in problems with technologies simply because everything is being pushed too hard, sold from all the cracks. They shout from everywhere: “Look, what a thing, this is the newest thing, the most beautiful thing in the world, suitable for absolutely everyone!” Well, this ... usually it all turns out to be just a temptation, and then you have to throw it all away. Perhaps all because I am already old and look at such things with a great deal of skepticism when people run out and say that they have found the One, Most Correct Way to Create the Best Technologies. At that moment, a voice wakes up inside me, which says: "Well, crap!".

Michael: Indeed, how often have we heard about the next silver bullet?

Tim: Exactly, and this is the usual course of things! For example ... it seems that this has already become a joke around the world, but here people often talk about blockchain technology. And they really make sense in certain situations! When you really need reliable evidence of events that the system is working and that no one has deceived us, when you have security problems and all that jazz mixed up together, the blockchain makes sense. But when they say that Blockchain is now sweeping around the world, sweeping away everything in its path? Dream more! This is a very expensive and complex technology. Technically complex, time consuming. Including purely algorithmically, every time you need to recount the math, with the slightest change ... and this is a great idea - but only for certain cases. I have a whole life and career about this: interesting ideas in very specific situations. It is very important to understand what kind of situation is yours.

Michael: Yes, the main “question of life, the universe and all that”: is this technology or approach suitable for your situation or not?

Tim: This question can already be discussed with the technology group. May even attract some kind of consultant. Take a look at the project and understand - will we do something right and useful now, better than before? Maybe it will do, or maybe not. But most importantly, do not make such a decision by default, simply because someone took and blurted out: “We desperately need a blockchain! I just read about it in a magazine in an airplane! ” Really? This is not even funny.

The mythical "DevoS Engineer"

Oleg: Now everyone is introducing devops. Someone reads on the Internet about devops, and tomorrow on the recruiting site there is another vacancy of “devops engineer” . Here I would like to draw attention to: do you think this term, "devops engineer", has the right to life? There is an opinion that devops is a culture, and here something does not fit together.

Tim: That's it. Let them then immediately give some explanation for this term. Something that is unique. Until they prove that there is some unique combination of skills behind such a vacancy, I won’t buy it! I mean, well, here we have the name of the post, "DevOps Engineer", an interesting name, yes, what's next? Job titles are generally a very interesting thing. Let's say a “developer” is what is it all about? Different organizations mean completely different things. In some companies, high-class programmers write tests that make more sense than tests written by special professional testers in other companies. So how are they now programmers or testers?

Yes, we have job titles, but if you ask questions for a long enough time, in the end it turns out that we are all problem solvers. We are the seekers of solutions, and someone has some technical skills, while someone else has others. If you live in an environment where DevOps has penetrated, you are engaged in integration of development and administration, and this activity has some rather important goal. But if you ask what exactly you are doing and what you are responsible for, it turns out that people have been doing all these things from time immemorial. “I am responsible for architecture”, “I am responsible for databases” and so on, whatever, you see - all this was before the “devoops”.

When someone tells me the name of their post, I’m not that much to listen. Better let him tell you what he is actually responsible for, this will make it possible to understand the question much better. My favorite example is when a person claims to be a “project manager”. What? It doesn’t mean anything, I still don’t know what you are doing. The project manager can be a developer, a leader of a four-person team, writing code, working work, which has become a team leader, which people themselves recognize among themselves as a leader. And also, a project manager can be a manager managing six hundred people on a project, managing other managers, responsible for scheduling and budgeting, that's all. These are two completely different worlds! But their position sounds the same.

Let's turn it somehow differently. What do you really understand, have a lot of experience, have talent? Why take responsibility for yourself because you think you can do the job? And here someone will immediately begin to deny: no, no, no, I don’t have any desire to engage in project resources, it’s not my business, I’m a technical dude and versed in usability and user interfaces, I absolutely don’t want to manage armies of people, let me better go work work.

And by the way, I am a big supporter of the approach in which this separation of skills works normally. In which technical experts can grow as far as they want. Nevertheless, I still meet organizations where techies complain: I have to go into project management, because this is the only way in this company. It happens that this leads to nightmare outcomes. The best techies are absolutely no managers, and the best managers can not cope with technology. Let's be honest in this regard.

I see a big request for this now. If you are a techie, then your company can help you, but regardless of this, you really need to find your own career path, because technology continues to change, and you need to reinvent yourself with them! For twenty years, technology can change at least five times. Technology is a weird thing ...

“Experts Around”

Michael: How can people cope with such a speed of technology change? Their complexity is growing, the number is growing, the total amount of communication between people is also growing, and it turns out - you can not become an "expert on everything."

Tim: Right! If you are engaged in technology - yes, you definitely need to choose something specific and delve into that. In some technology that your organization considers useful (and perhaps it will prove to be useful). And if you are no longer interested in it - you would never have believed that I would say this - well, maybe you should go to some other organization where the technologies are more interesting or easier to study.

But in general, yes, you are right. Technologies are growing in all directions at once, no one can say "I am an expert technologist in all technologies that I have." On the other hand, there are sponge people who literally absorb technological knowledge that are crazy about them. I saw a couple of such people, they literally breathe and live it, it is useful and interesting to talk with them. They study not only what is happening inside the organization, but in general, they talk about it, they are also really cool technologists, they are very conscious and purposeful. They just try to stay on the crest of the wave, regardless of what their main job is, because their passion is the movement of Technology, the advancement of technology. If you suddenly meet such a person, you should go to lunch with him and discuss different cool things at lunch. I think any organization needs at least a couple of such people.

Risks and Uncertainty

Michael: Honored Engineers, yes. Let us, while we have time, touch upon risk management. We began this interview with a discussion of medical software, where errors can lead to sad consequences. Next, we talked about the Lunar Program, where the cost of error is millions of dollars, and possibly a few human lives. But now I see the opposite movement in the industry, people do not think about risks, do not try to predict them, do not even watch them.

Oleg: Move fast and break things!

Michael: Yes, move fast, break things, more and more things - and so on until you die from something. From your point of view, how is it now for an ordinary developer to approach the study of risk management?

Tim: Let's draw a line here between two things: risks and uncertainty. These are different things. Uncertainty arises when you do not have enough data at any given point in time to arrive at an exact answer. For example, at the very early stage of the project, if someone asks you, “when will you finish work”, if you are an honest enough person, you will say “I have no idea”. You just don’t know, and that’s normal. You have not yet studied the problems and are not familiar with the team, you do not know their skills, and so on. This is uncertainty.

Risks arise when potential problems can already be identified. Such a thing can happen, its probability is greater than zero, but less than one hundred percent, somewhere in between. Because of it, anything can happen, starting from delays and unnecessary work, but also up to a fatal outcome for the project. The outcome, when you say guys, we turn off the umbrellas and leave the beach, we will never finish it, it's all over, period. We made the assumption that this thing will work, but it does not work at all, it's time to stop. .

, , . , – , . , , , , , ? ? , ? , : , . , , , - . : , .

, . , : , , - , . , , . , , , .

, ? , . , . 100%, : «, , !». . – , , , ! , , , : « – , – ». , - .

, , – . , . . !

: . , . ?

: , , – . , . - ? , , , , . , , . « , – ». . ( !) , . . , , – , . , . , . , , , , , , … , , . , , . . , , , !

: , , - , (, ) .

: . , , , . …

: – , .

: ! , , , , , , . , , , , . , , . , Agile – , , , . .

: - ? , – Java- -, . , « » , ? ?

: – . . , , . : , , : , ! ? , ? . , . , . « – » — , . , , , .

: , , . , : , , . , , . ?

: , . , , , , , «». , . , - . , , , . , , , , .

, . , – . . – . - -, , , , - . - . , XP — , . - XP – , . , ! , , ! Awful - . , , . , - .

: . , , . , , , . , . . , .

: , : « , ! . , , !». , , ? , – , . . , . – . . , - . , , – , ? ! , - , , . , , - , , . , – , . , , , , !

: , ? , !

: , . , , , – , . , . , . . , , , .

: , , , , . .

: , , , – . , , , . , , , . , . , .

: , , , , , , . , , , ! , ?

: ? Hm. , - . , - , : , , … ? ! -, . , , , , – ? !

: !

: , , . , , , . . .

: , - .

: , , . , … … !

: , «». , , . , - . , , - , . . .

: , , . - ? , , …

: , . , . , , . , . , , , . , , . , . , , , , . . , , . , , -. , - . , , : «, , - !». , . – , . , .

: « », - , ? 80/20, - .

: - , « », , … , , . - – . «, , , , ? ? ?». , ?

I am trying to explain that you should not get mad at the current situation too much. You need to discuss it, to truly understand what could have gone wrong, and how to prevent such things in the future. If, nevertheless, the problem manifests itself, how we will fight it, how to restrain it.

For me, it all looks scary. People deal with complex, unpleasant problems, and continue to pretend that if they simply cross their fingers and hope for the best, this very “best” will really happen. No, that doesn't work.

Engage in risk management!

Michael: In your opinion, how many organizations are involved in risk management?

Tim: What infuriates me is that people just write down risks, look at the resulting list and go to work. In fact, identifying risks for them is risk management. But for me this sounds like a reason for the question: well, there is a list, what exactly will you change? You need to change your standard sequence of actions taking into account these risks. If there is any most difficult part of the work, you need to do it, and only then move on to the simpler one. At the very first sprints, start solving complex problems. This is already similar to risk management. But usually people cannot say what they changed after compiling a list of risks.

Mikhail: And yet, how many such risk management companies are five percent?

Tim: Unfortunately, it’s unpleasant for me to say this, but this is some very insignificant part. But more than five, because there are really big projects, and they simply cannot exist unless they do at least something. Let's just say that I would be very surprised if it is at least 25%. Small projects usually answer such questions in this way: if the problem touches us, then we will solve it. Then they successfully plunge into the problem, and are engaged in problem management and crisis management. When you try to solve a problem, but the problem is not solved - welcome to crisis management.

Yes, I often hear, "we will solve problems as they become available." Will we be right? Will we definitely decide?

Oleg: You can do it naively and simply write important invariants into the project charter, and if the invariants break down, just restart the project. It turns out in a very pembucco manner.

Mikhail: Yes, it happened to me that when the risks worked, the project was simply redefined. Nice, bingo, the problem is solved, no more worries!

Tim: Press the reset button! No, that doesn't work.

Keynote at DevOops 2019

Michael: We approach the last question of this interview. Are you coming to the next DevOops with a keynote, could you open the veil of secrecy over what you are going to tell?

Tim: Right now, six of them are writing a book about working culture, the unspoken rules of organizations. Culture is set by the core values ​​of the organization. Usually people don’t notice this, but we, working in consulting for many years, are used to noticing it. You go into the company, and just a few minutes later you begin to feel what is happening. We call it "aroma." Sometimes this scent is really good, and sometimes it's, well, oops. Different organizations have very different things.

Mikhail: I have also been working in consulting for years and I understand well what you are talking about.

Tim: Actually, one of the things that is worth talking about on the keynote is that not everything is determined by the company. You and your team, as a community - you have your own team culture. It can be either the whole company, or a separate department, a separate team. But before you said: that’s what we believe in, that’s important ... You cannot change culture before the values ​​and beliefs behind concrete actions have been realized. Behavior is easy to observe, and finding belief is difficult. DevOps is just a great example of how things get harder and harder. Interactions become only more complicated, they do not become cleaner or more understandable at all, so you should think about what you believe in and what everyone around is silent about.

If you want to achieve quick results, here’s a good topic: have you seen companies in which no one says “I don’t know”? There are places in which you need to literally torture a person until he admits that he does not know something. Everyone knows everything, everybody is incredible scholars. You approach any person, and he has to instantly answer something to the question. Instead of saying "I don't know." Hooray, they hired a crowd of scholars! And in some cultures it’s very dangerous to say “I don’t know”, it can be perceived as a manifestation of weakness. There are organizations in which, on the contrary, everyone can say "I don’t know." It’s completely legal there, and if someone in response to a question starts rubbing game, it’s perfectly normal to answer: “You don’t understand what you’re talking about, right?” And reduce it all in earnest.

Ideally, I would like to have a job where you could be happy all the time. It will not be easy, not every day is sunny and pleasant, sometimes you need to work hard, but when you start to summarize, it turns out: wow, this is really a wonderful place, I work well here, both emotionally and intellectually. And there are companies that you go into as a consultant and instantly realize that you wouldn’t have survived for three months and would have run away in horror. That's what I want to talk about on the report.

Tim Lister will arrive with the Keynote "Characters, community, and culture: Important factors for prosperity" at the DevOops 2019 conference, which will be held October 29-30, 2019 in St. Petersburg. Tickets can be purchased on the official website . See you at DevOops!