Loading summary
A
This is the Effective Engineering Manager podcast. In today's episode, Adam and Slava talk about the importance of a management strategy and how to build one, regardless of whichever level you're at. Welcome to the Effective Engineering Manager podcast.
B
It's good to be here. It's your time today, Adam, what would you like to talk about?
A
Hey Slava, great to be here with you as well. And we have an interesting topic today that hopefully will inspire some good discussion between us. And it's around what we call building an effective strategy as an engineering manager. Whether you're going into engineering management or you're already seasoned, I think this is an applicable skill to develop. And building a strategy is around distinguishing the day to day tactical tasks as an engineering manager, managing people, managing managing tasks, the dynamic changes of a product, the KTLO anything you do on a day to day basis from the bigger picture. And one of the most important things to become a successful or ineffective engineering manager is having a strategy that you put together and evolve and drive towards some sort of impactful change. And notice we're very sensitive to not necessarily tie it to a timeline. It's not about saying what you're doing in the next month, the next quarter, the next year. A strategy is something that can actually transcend several of those data points. It could be something that can be multi year, but the key thing is that the strategy has to be a success oriented strategy and something that aligns to a, a sort of triangulation that we're going to talk about of the things that you need to implement that strategy. And this is distinguishing because a strategy is the way that you help catapult yourself as an engineering manager into a more effective or stronger leadership role as you grow and a path towards growing your career and also distinguishes yourself from sort of an individual level set of responsibilities as a individual contributor. You're used to being told what to do given tasks and oftentimes there's a feeling that once you become a manager that you're still going to be told what to do and you just have to implement whatever you're told what to do. And part of that is true, but the more important part and where leadership and effective leadership comes out of this is your ability to be able to drive the organization in a particular direction that impacts the overall business as a whole. What are your thoughts on that? Slava?
B
Yes, I think it's good stuff and I was just thinking that it applies on all levels. Even if you are a frontline engineering manager, maybe even have three, five folks or if you're a senior director or a VP or a svp, I think having a strategy is fundamental because it allows the entire team vertically and horizontally know what we are doing, where we are going, how we are going to get there, and how it's going to contribute to the end goal of the entire enterprise. And I think it's fundamental to have something like this because otherwise it's just taking what's given to you and trying to make it work.
A
Absolutely. And I think it also recognizes the fact that hopefully a lot of the reason why you or your peers have become engineering managers is to participate in leadership, participate in building the strategy. It's not just the CEO or the C suite folks that are responsible for that, it's really everyone in leadership. And that helps your organization grow, it helps your team grow, and it certainly is going to help your own career as well. So having an effective strategy and the ability to implement and execute on that is very key and very important in a lot of these areas.
B
Yeah, good stuff. And it's a good point which just made me think strategy exists, if you're doing our jobs well, exists on all levels, from the highest levels to the lowest levels. It's just the level of detail and what the objectives are different. But otherwise I would totally say that if you're doing your job well, you have to have a strategy regardless of your level.
A
Absolutely. And I think you articulate that very well when you. Like you just said, the objectives can be different, but the core need for having a strategy and being able to execute on that effectively is going to be key regardless of where you are in the organization. And so it's important even from day one to have a semblance of that. And we're going to get into that in a short bit. But Slava, just a little bit of anecdotal stuff from your experience in your history as an engineering manager. Where has strategy helped you and anything you want to share with folks, before we get into the details here, I'll.
B
Give an example, maybe without sharing the names. One example is when I drove the establishment of cicd. That's a fundamental practice which contributes to the overall success of the company. And getting there takes time, often months and quarters. And if it's an established organization that does not have CI cd, it takes years, maybe two to three years to get there from when the developer checks in something in the version control system and in two hours it's in production. It takes. Takes lots of work. And building this shared goal that 100% contributes to the company's success and also has a high level plan. Maybe five, 10 key parts, key objectives, feeding into the vision. And the vision in this case was like I mentioned, developer checks something in version control and it's in production in two hours. And that helped because without knowing where are we going as a team? How do we know if we are succeeding? And not being able to measure whether we are succeeding or not? Are we 50%, 30%, 90%? We are not going to get there, we are going to get distracted. Other things are going to come up. And having this a good strategy I think brings focus, it brings shared and mutual understanding and alignment and buy in from all participants and agreement that these are the bold goals and they are going there and we are doing it. And we will know that we know that we are succeeding and we will know that we've been successful. That I think is key.
A
Yeah, absolutely. And that's a great example because getting CI CD requires a great deal of collaboration. You can't work on your own on that. And number two, it's foundational to the ability to be successful. And I guess three, it highlights, it gives you the level of visibility and transparency. You need to know how well you're actually doing and how productive you can be. So it like checks all the boxes. So that's a great, great story. And I think that leads into what we actually mean by a strategy. So let's dive into that. You know, we talk about, we, you know, so far we've used the word strategy and we use it kind of loosely and I think, of course, you know, there's, there's some obvious parts to what a strategy is. Right. You know, it's important to have some sort of organization and direction to what you do. But let's define it a little bit more succinctly and specifically for the, for the, the folks that are listening here. It's based on having really key building blocks. And what we call, what we're going to call here is the triangulation of three things that need to work together. So you create a strategy that's cohesive and coherent as well, but also something that's going to be success oriented. And the triangulation is around direction, people and a business need. So let's talk, let's dive into that. The first thing is direction and the building block for direction is vision. So as an engineering manager, this is actually where you get to be somewhat creative, somewhat innovative and somewhat free spirited in your thought process on what is the North Star, what is the landscape of what you're trying to build. And it's not just the product you're trying to build. It's not just the culture and it's not even just the organizational impact. It's really all of those things combined. It's what do you want to leave as the mark on the organization once this strategy sort of comes to fruition and results in meaningful business value. In your case, I'm sure part of the vision was having a CICD platform that can enable the business to build more things and be more responsive to the market and get better visibility. So that's vision and tied to direction. The next is goals. So the goals, and this is, I think, where a lot of people who have a strategy often fail to be successful because the goals are often not well defined and are not goals that evolve. So what do we mean by that? A goal should be something that has a well defined milestone, a well defined purpose, and it has to be bought into by the people that are contributing to make that goal happen. It could be product engineers, it could be a marketing business or sales portion. It could be an infrastructural component where you've got opponents parts of the organization that have to be able to support in building that. But it has to kind of show your stepping stones towards getting there. And we'll talk a little bit about the need to iterate on that in a bit. But having a set of goals and clear milestones that help lead to that North Star vision is key. And that's part of people. The next thing that's tied to people as a building block is being strengths based. Again, anybody can come up with a strategy and a vision for virtually anything. That's where the creative part comes into play. But if it's not tied to the strengths that you have within the team, within the organization and within the wheelhouse that you have to work from, you're not going to be successful. If the strategy is predicated too much on filling a gap in strengths or skills. You're just going to be working from a deficit and wasting time until you get to that point. So it should be strengths based. You should be looking at the organization that you currently have and say, what do we do really well and how can can we turn that into making those next strides towards that vision? So that's people. The goals and strengths based part also work together towards a need. So having a vision is great. Having strengths and skills and people ready to do it is also great. But there has to be a tangible business need and it could Be a small business need that morphs into something larger. You might have a vision that hey, we want to go and catapult the business into this one whole area. Well, you got to start with the immediate business need or the alignment to what the organization is marching towards to even get the buy in to be able to do that. So there has to be clear business need, there has to be clear translation of the goals that you're setting for yourself in these milestones and the vision towards that business need. And then the last part in the building block that's really tied to all three direction people in need is the strategy has to be well documented and measurable. Documenting a strategy is I think Slava, as you so keenly alluded to in our pre chat discussion on this, is you got to put it on paper. You got to put it on paper. It doesn't mean it's set in stone, but if it's not on paper, it's not material, it's not something that you can actually start start using and sharing. So documenting it the best way possible, highlighting the goals, highlighting the milestones, highlighting what your North Star is and iterating on that as you get more buy in is key. And that also has to be tied to how measurable it can be. Now measurability can come from a variety of areas. It can come from engineering level measurability or metrics that we typically use, how productive a team is, quality metrics, time to market, all those kind of things. It could also be tied to how cost effective the strategy. Is this going to lead to cost savings over time? Especially if you're in the software business and you're building things that require a lot of infrastructural components that can easily and very quickly exceed your budgets and then other things. Is business value measurable business value? How much revenue are you going to help generate from what you're doing? How much profitability are you going to generate? Is it aligned to where your company is in the stratus of its growth goals? If it's a startup company and you're really just trying to get those first few customers out there, your measurements for that will be slightly different than a more mature or larger company that is looking to be more mindful of their bottom line or be careful of where they put their growth assets, especially if it's a public company, right? Being tied to the need to always appease the market. So again, it comes back to having a realistic and tangible strategy, but one that is very much measurable and you can hold yourself accountable to move that. So those are the key building blocks in this triangulation of direction, people and need that we kind of call as the foundation for a strategy. Slava, you have any thoughts on that?
B
Yes, I really like your notion of the strategy being grounded in reality. You mentioned you should count on people that you have and count on the capabilities. And I want to add that as the strategy is built or have been built, I think it's fundamental that the strategy is workable from day one. Because if the strategy has certain preconditions that are required to happen for the team to start working on it, this is not a strategy, it's a hallucination. Because if you say that I have to have XYZ for my strategy to begin to work, it means that this long term, high level plan is just not ready. It's either because if you need something to happen, it has to be a part of it, or maybe it's a signal that if a lot has to happen for the strategy to begin to progress, maybe it's a signal that it's too remote from reality and this has to be sort of like an internal or inner self health check on whether it's grounded in reality or not. Or for example, if say, hey, you're going to build XYZ and for this to happen, we have to hire 50 people. Oh, here's your problem. When are you going to get those people? How much is going to cost? What's going to be the impact on the margins? I feel that it's critical to stay grounded. And being able to first step should be the step that already implements your vision. So that's the thought.
A
Yeah, Exactly. And I 100% agree with that. One of the things we always want to be practical with the advice and what we share here, we're not trying to be pie in the sky or vague on these things. And so we're going to tie this to actual experiences that we've seen or used or seem to work very effectively. Because I know a lot of people out there may be saying, okay, that's all great, but how do you, what are the ways that you can go about building that strategy? And I think you're absolutely right. Being very aware of where you're at today is super important. And being aware of saying, you're right. If you need 150 people or specialty skill to get this done, if that's not something you can attain right away, maybe you don't have the right strategy. And it doesn't mean that that can't be your vision either. You can still have that as part of your vision, but work backwards from that and say, okay, to get to that, maybe we need 10 steps instead of just five steps. And those 10 steps actually have to start with very elementary steps from where you're at today to be able to get to that. So maybe say, okay, maybe I look to hire one person who can be specialty in this area. But until then, we're going to work on the strengths that we currently have to devote to a particular task that's going to move the needle along in the direction that you want. So it's directionally oriented and also allows you to have. It doesn't force you to be shortsighted. It doesn't force you to come back and say, well, our business is not going to be there, so why should I care about it? You still care about it, and you absolutely should still try to find a way to get there. But you got to navigate that 100% agree with that. So with that, maybe we dive into some of the approach that we're talking about here. I think the first thing is as a engineering manager, forget about the fact that you've got layers of management above you for the moment. Imagine yourself as the CEO of your own organization. And like you said, it could be 3, 5 people, 10 people, 20 people, 100 people, doesn't matter. But imagine yourself as a CEO, meaning you were solely responsible for everyone under you and sort of around you, and what decisions would you make to help get the most out of that group and align to the business goals? So I think sometimes we feel so shackled by what we think people above us want us to do, and we don't allow ourselves to really think about the need. And reality is people above us are expecting us to kind of assess because we're closer to it, to some of the trenches, and understand what we need. So imagine yourself as the CEO of the organization and start by thinking about, okay, what would happen if your organization 2x3x or 5x'd itself? What would that look like? What would it mean to get to that point? What would it mean that you're doing well? What would it mean for the responsibilities of the group that you're responsible for? What types of new business opportunities could open up by having a larger organization? What things would not? So imagining yourself not being locked to the same size organization you have today and thinking about what it would take is going to be pivotal towards the growth goals. The next thing is, as we sort of alluded to work backwards, take your vision, you're sort of your North Star, and work backwards incrementally. So reverse engineer your goals, your milestones, all the way back to where you're at today and see that you have a clear path forward and backward. Next, tie your vision to the core principles or values. So one of the key things, especially as an engineering manager that will help you make you successful irregardless, is your ability to always be oriented around direct business value. What is it that the business is trying to do? What is the core mission of the company? What is the core mission of the engineering organization? And make sure your strategy is completely tied to that and has some relevance to that. So if your company is all about growing in a particular space in the industry or a particular market, then your strategy needs to address that. Even if you don't think the work that you're doing is directly related, it has to. At the end of the day, especially to get the money and budget that you need and support, you're going to need to show direct business value and you're going to need to be able to show that to business value to folks that don't speak engineering. So that's another challenge, but a very important element. And as we talked about, the goals that you set need to be tied to the strengths and capabilities of the team that you have and its members. Getting the most out of your people is one of the most important things. If you think about like we take an analogy to a sports team, what are the most effective sports coaches? You know, historically? The ones who, you know, take a team and the assemble all the parts to maximize the value out of them and get the most out of them so that they're working as a well operated machine. It's not someone who's given all the best people and just getting productivity out of them because it's sort of expected out of the highest performers? No, it's taking a more realistic mix of folks and capabilities and maximizing what they're able to produce by looking at their individual strengths and their collective strengths as well. Next, and this is a really key thing that we're going to lean into here is you need to be able to build partnerships across the organization. So as an engineering manager, arguably one of the most important responsibilities or capabilities I should say that you have is the ability to kind of work laterally and you're expected to and find your peers in other areas and say, okay, here's the strategy I'm trying to build. I want to partner in this. You Know, it's not just tunnel vision towards one goal, it's a collective goal because it's about making the larger organization far more successful as a result. I'll pause there for a second since I know it's a really important one. Slava, any thoughts on just the importance of building partnerships towards a strategy?
B
Yes, I think it's critical because if we build strategies which are not taking into account our partners in our bosses, chances of us being successful are not very high. And it's important to get a buy in from our chain of command and it's just very simple. If we are doing something that they don't want us to do, it's not happening. And same thing with partners in the modern innovation organization, modern software development organization. We depend on each other and we depend on our qa, we depend on our operations teams, we depend on our product teams. And not having them in the loop is going to be problematic because at some point you will need their help and if they see it as imposed on them by your will and that's it, they may not be willing to participate. And that's why it's so important to have a go or let your own team to have a go at your thinking, maybe accommodate as much as you can and doing the same thing with your key partners and soliciting feedback, soliciting input, asking does it make sense to you as my partner and do you think we can work on this together? And in the end, once everyone is on the same page, bring it to your own boss and having the same conversation that hey, this is what the thinking, long term, long term thinking is. This is how it fits into your objectives. This is how partners are on the same page as well and the team is happy to have a go at it. It's going to be very easy. But accounting for the goals of your own chain of command is critical. Just like because partners is a, are important too because without them it's impossible. But without your chain of command being on the same page and your team being on the same page, just going to miss.
A
Yeah, absolutely. And I think you bring up and mention it, I think very well when you say depends on relationship, we don't overstate. You know, we don't, I think we understate that too much. We, you know, we often feel that a task we're being asked to do or our sphere of responsibility is, you know, in its own silo whether we, whether we consciously think it or not. We just think, hey, I got to get what I'm asked to do done. And you don't think about the depends on say oh, actually depend on these other teams and they depend on you as well. Right. So it's a cross thing. And another thing you mentioned the fact that keeping your management in the loop, you say oh well that's sure, we absolutely have to do that. But I think you touch on a really, really important thing that the depends on relationship that you have laterally also extends as you move up as well. So you know, you might have a peer in another team who you work very well with and building that relationship is actually going to only positively impact your boss and that person's boss from being able to have that level of relationship as well. And you know, everything rolls all the way up and then by the time you get up to whoever the head of your organization is, they're going to see that level of synergy and it's almost going to in not every case, but I think in a lot of cases just necessitate the fact that oh yeah, we just have to do this or we got to continue doing this because the teams are already doing a really good job of it. And we want to highlight that it's a way that you can sort of have a ground up impact. If you as an engineering manager have a great partnership with at least one or two others in different teams at your same level and you're working on a common strategy together and producing, that's only going to work to your advantage. I think that's bring up a really key point there and then just kind of going on a little bit more in the approach here. We talked a little bit about this earlier, but the need to iterate. One of the things that saddles a strategy, even a well defined strategy, is how versatile or flexible it is. And that a strategy shouldn't be something that's completely set in stone, immutable. And that's the only thing you're working towards because as time goes on, things will impact your ability to implement the strategy but also affect the strategy. Right. Business goals could change the relationships in the company, can change the product direction, the market, everything can change. I mean just look at the last three, four years of things and how much variability there was based on things that we could not control. And so being able to as an engineering manager, your ability to pivot and iterate is key. So from day one you should say, look, this strategy is not necessarily it's a solid strategy, it's got a solid vision set in stone. It's not set in stone and we're going to make adjustments over time, but that also means you have to deliver things iteratively too, right? Show incremental progress. Depending on your organization, it could be weekly, although that might be a little bit too severe, but it could be monthly, it could be quarterly. But something that is showing that you're continuing to iterate and make progress on and say, hey, we're making progress. You have a lot of success and data points to show that and that you're also proactively pivoting on the strategy as you need to. And you may have to change your vision over time, but hopefully you don't. But it doesn't mean your goals and the way that you get there doesn't have to change. So iteration and being able to progress on that is so key. We talked about communication. Can't understate that enough that you have to clearly communicate regularly with all your stakeholders, both laterally, upwards and downwards. You have to communicate to people below you as well. Don't take for granted that they just understand the strategy. Oftentimes as we know, that can be some of the most time consuming because you have to reiterate that multiple times with multiple groups, multiple sessions. You have to get the buy in of everybody. And the last thing that we'll say is you have to embrace the dynamics of working globally as well. In today's day and age, I think more than ever organizations are far more cross regional, global. And looking at the strengths and resources that you have should not be limited to your home turf. It should be looking at wherever your company is geographically stated, wherever anybody can contribute. And having that ability for sort of around the sun work may be beneficial. It may also enhance your cape, your ability as an engineering manager to get things done across verticals. Right. If you're, let's say you, let's say you're trying to attach to a market that's in Europe and you're currently in the U.S. well, having people on the ground in Europe or Asia or wherever closest to your market is, is going to be key. And working with them and partnering with them to say, hey, here's the strategy that we have, you're part of it, but we want to get your feedback. And you're a key partner in this too. And making them feel committed as well is also going to be key. So don't just look in your own home turf, kind of expand globally and be aware of where your organization has footing to take advantage of that as well. And that'll also enhance the ability of the company to Scale. So those are some of the key things that we feel are very practical that should be able to apply to any engineering manager. Whether you're new to the role or seasoned or not. You can start on a lot of these things fairly immediately. Slava, any thoughts on that?
B
Yeah, good stuff. I really like what you said about iteration and that things change and what it also tells us that the strategy has to be. Well, first of all, there has to be division, which is the North Star. No matter how winding the path is, ideally we should be working towards it. And there are fundamental changes sometimes in companies, in markets. And maybe your North Star is not North Star anymore, maybe there are no stars, maybe there's something else. But the goals, the objectives and the high level plan has to be flexible. And when we say high level it means that, it doesn't mean that, it has to be vague and it just means that whoever reads it should be able to have a good idea how we are going to get there, number one. But also because of the, the only constant is the change. I would say that long term, long term objectives have to be high level. Because for them not to be high level, we have to specify everything on the sprint level and assign work to people on a bi weekly basis. And if you try to do something like this for two, three, five year plan or the strategy, it's impossible or it's going to get out of date within a couple of weeks. But it also means that how do you pivot when you have high level objectives? And my practice, which I've done and it really worked, we keep everything year out. It should be able to fit on a single slide on a PowerPoint with just a few pictures. It's about these are the things we would like to do and we believe that are going to get there two years out, it has to be maybe two, three pictures. And I'm saying pictures because this is just a visual because when you write your strategy document, you have to go into a bit of a detail what it is, why it is and how it's going to be contributing to the business value and to the success of the strategy. Everything under a year needs to be, needs to be actually planned. Because years there or maybe six months to a year, maybe this is where the actual commitments of people and money happening. And I would say your next milestone, which or next objective, which is a year out has to be planned out on a quarterly basis. This is what you are going to lend. First quarter, second quarter, third quarter, fourth quarter and first and the couple of quarters Ahead of you have to be planned, turned into a project plan, because this is where we're actually going to be doing things and delivering things, building working hardware, building working software, building working infrastructures and all the good stuff. So essentially it means that the further.
A
Out.
B
The objectives, the more high level they should be. But not on a bullshit level high level, the closer to the current moment, the more precise this should be. And what it allows us is, allows us to do things and deliver things today, tomorrow, learn from them, and based on that learning, adjust what's in front of us and have those pivots. Because if you plan everything on the same level of precision, then pivoting is going to be very hard or impossible. And it's also going to be hard because it's going to take month and month to plan out three, five years of work. Yet small increments with deliverables that allows us to assess whether our high level plan still makes sense are important. So high level for things which are further away and higher and higher fidelity and higher, higher precision as they reach the current moment. And that I found more practical than either not planning at all or trying to plan the whole bloody thing.
A
Yeah. And that's so key. I mean, you remind all our listeners.
B
That.
A
You still got to get things done at the end of the day. Right. And your ability to be able to abstract things that's still meaningful. Right. Whether it's a year out or more, is going to be key to just the validity of your strategy as well. Right. Like you said, if everything has the same fidelity as far as time and scope and all that, no one's going to take you seriously because it's just going to look like an idea. But your ability to say, okay, here's where we want to go, here's our North Star, here's where we start. And we know we have high confidence we can get these things done in the near term, but at the same time, we're going to be very mindful to pivot after each one of those getting feedback, that feedback loop that we need. I think it's actually a really key point that you make, and it's something we as engineering managers should never abandon.
B
Okay, Adam, that was good stuff. A very thorough discussion on the effective strategies for engineering managers. Could you give us a checklist that our listeners can use to confirm to themselves that what they're doing is working?
A
Sure, absolutely. So checklist is the following, Number one, build a strategy early on with a basic foundation of core vision, set of achievable goals, and align to the strengths of the team. What we call the triangulation of direction. People in need, make sure they all align together and you're telling the same story. Number two, the strategy itself should be challenging but reasonable and represent the team that you have at 2x or 3x growth. So don't build a strategy that's going to just end tomorrow because you're successful in a month. It should be challenging, should align to everything and it should represent the ability to have growth because growth will be a part of the puzzle. Number three, the strategy should be aligned to your business goals intimately. Be aware of where your business is, where they're going and how you can help. And your strategy should be aligned on at least one of those business goals, if not multiple. Because a business goal could be there could be a financial goal, there could be a market goal, there could be a product goal, there could be, you know, if you're a public company, some kind of, you know, public, another public financial goal as well. Number four, use your lateral relationships to build partnerships toward a common set of goal. Very, very key. Use everything you can to get everyone bought into the strategy, particularly laterally. And lastly, drive and deliver an effective communication plan with your stakeholders and upper management to show progress on your strategy and opportunities for growth. The communication plan in itself is going to be a key thing that helps you as an engineering manager not only get better visibility, but help practice communicating and getting that feedback, especially from upper level management so that you can take that and use that to tweak the strategy and show them that you can iterate. So very, very key to build an effective communication plan. Follow up on it regularly. Be proactive in meeting with your boss and boss's boss and other key stakeholders and sharing the progress on the strategy. That will be very key, especially if you come with good partnerships supporting that underneath the hood. So those are the key five things that we feel are key. We could talk about this topic for plenty days, but hopefully it's something that our listeners can go and start practicing tomorrow.
B
Thank you, Adam. That was good stuff.
A
Thank you, Slava. Appreciate it. And for all our listeners out there, we hope this was helpful for you. We'd appreciate any feedback. Please feel free to email us@contactffectiveem.com Please also vote and rate us on whatever platform you're using to tune into this podcast. And please also reach out to us if you have any other questions or topics for future discussion. We'd love to hear from you. And until next episode, keep managing effectively.
Release Date: December 31, 2023
Hosts: Slava Imeshev and Adam Axelrod
In this episode of the Effective Engineering Manager podcast, hosts Adam Axelrod and Slava Imeshev explore the critical role of strategy in engineering management. They break down why having a strategy is essential at all levels of leadership, from frontline manager to VP. The discussion provides a practical framework for building and executing a results-oriented strategy, emphasizing the overlap between individual leadership, team alignment, business impact, and organizational growth. Real-world anecdotes, actionable advice, and a concluding checklist make this conversation invaluable for both new and experienced engineering managers.
[00:20–04:56]
“Building a strategy is around distinguishing the day to day tactical tasks ... from the bigger picture.” – Adam [00:20]
“If you're doing your job well, you have to have a strategy regardless of your level.” – Slava [04:19]
[02:47–05:38]
[05:38–07:50]
“The vision ... was like I mentioned, developer checks something in version control and it's in production in two hours.” – Slava [05:54]
[07:50–15:16]
Three Pillars of an Effective Strategy:
“The triangulation is around direction, people and a business need.” – Adam [08:32]
Document and Make It Measurable:
A strategy must be written down and tied to objective metrics—be it productivity, cost, or business value.
[15:16–17:27]
"...if the strategy has certain preconditions ... this is not a strategy, it's a hallucination." – Slava [15:42]
[17:27–23:43]
[23:43–26:16]
"If we build strategies which are not taking into account our partners in our bosses, chances of us being successful are not very high." – Slava [23:45]
[26:16–32:01]
“A strategy shouldn't be something that's completely set in stone...” – Adam [27:21]
[32:01–36:51]
“The further out the objectives, the more high level they should be...the closer to the current moment, the more precise this should be.” – Slava [35:38]
[38:11–40:34]
“The strategy should be challenging but reasonable ... represent the team at 2x or 3x growth.” – Adam [38:35]
| Segment | Start | |-----------------------------------------------|------------| | What is Strategy? | 00:20 | | Strategy at Every Level | 02:47 | | CI/CD Implementation Example | 05:38 | | The Triangulation Framework | 07:50 | | Grounding in Reality: Realistic Strategy | 15:16 | | Practical Steps in Building Strategy | 17:27 | | Partnerships and Getting Buy-In | 23:43 | | Iterative, Communicative, Global Strategy | 26:16 | | Planning Levels of Detail Over Time | 32:01 | | Strategy Checklist for Managers | 38:11 |