> Engineers are Already Owning the What, Why, and When in Startups
The thing is that they own these things only if there is a space to own it. But the space for such culture is built only by those who know it much better than any engineer in a team, by those who is in charge of it and can build the proper system with intentions (Product Lead/Founder).
I've struggled a lot in situations where I was really trying to own this, be a multiplier, lead the team in this way but the environment wasn't designed properly because even the Product Lead hasn't figured out anything and hasn't found answers to "why," "what," "when."
But when such culture exists, that's an insane opportunity to build a team of multipliers.
That resonates Vasiliy. You definitely need a product vision + set constraints and that comes from the leadership.
Normally, if that's not the case and even the leadership team is confused -> that trickles down to teams as well and we are more or less beng busy building some features but not actually being productive as we are not building the RIGHT things.
In such scenarios, my recommendation is to put your best effort with building useful things and being helpful. At the same time, the other part of being a multiplier (making everyone around you better, should still be the case, so I'd focus more on that side).
And yes, good call on when such culture exists (there is clear product vision and engineers are encouraged to own the full cycle) -> that's a really great environment to be in.
I love this article! I talk about similar issues in my blog. When my colleagues asking if AI will replace them, I answer: “You are an Engineer! Your job is to solve problems with or without writing code. AI is just a tool to help you write code(and make an exploration)”
The shift from pure coding expertise to impact-oriented engineering really resonates with what I'm seing in the industry. The contractor analogy is spot on becuase it highlights how stakeholders care about outcomes, not just activity metrics. What strikes me most is how the multiplier mindset naturally aligns with AI-assisted developement where the value isn't in writing every line of code, but in architecting solutions and enabling team velocity.
Glad that it resonates! And yes, companies, people and overall organizations care about outcomes, but a lot of times they misinterpret what actually they need to get to the desired outcomes :) And yes, multiplier mindset + AI-assisted Engineering is a powerful combo these days.
The tickets are the leverage, Jira studies what the optimal workflow is for getting things done. So, if you deeply integrate your process into a system that studies the most efficient workflow that is the leverage the ticket pusher can be set up to be the leverage.
There's definitely time and place for that as well. There is a specific Staff Archetype called: the builder, who focuses on hard tasks and going one task after the other. But the focus is on hard tasks and the ones that not many people can handle.
And also of course in regular environments, people who you can trust to get things done within the right timeframe and also quality are important. The problem comes if you are too relying just on pure ticket definitions and clear description to get your work done. Remember, if you can describe the task really well, AI can also handle them (especially low-complex tasks).
Love this, but with slightly different view when I think what always made a great (not good) engineer - one that understands the bigger picture, systems design, extensibility, scalability, reliability, flexibility, etc Those considerations resulted in systems that lasted and scaled. In my experience, using AI to generate code these aspects may have become even more important in terms of how to guide and invoke and course-correct AI code generators that often build exactly what you ask for without consideration for these things unless you explicitly ask for them. It can be narrowly focused, with recency bias, over-indexing on the latest set of prompts at the expense of previous consideration that had been accounted for and now begins to erode. It can also have been trained on masses of code that included good coding practices and bad. As someone invoking it, you need to be able to recognize when bad patterns are being repeated/introduced. Language can also matter here - think of the level of sophistication of the average Python coder vs the average say Rust coder. The code base being trained on in one language may, on average, model a higher level of sophistication than the other. How much attention was paid to the quality of code being used to train the system?
So, yes, the engineer of today must be a multiplier - one that understands architectural and systems design so as to effectively multiply towards systems the will be resilient, will scale, will accommodate new use cases and will last other tests of time.
Great perspective! You are definitely right. Good understanding of system design, and overall good practices are more important than ever. With AI, you can generate code based on your ask, but then how that code fits into the large system, that's what's really important to know and understand.
Based on recent report I checked -> a lot of engineers and engineering leaders mentioned that critical thinking is one of the most important skills for an engineer now and in the future as well. And that's the skill that enables you to really think if the code fits into the system or not (and not just blindly pasting it).
I really like the idea that engineers are moving more towards product managers / owners. I think AI is really going to split software engineering into two factions: one that is super technical and will be needed when AI coding tools can't get the job done right (deep technical knowledge) and those who understand the code AI is producing it, but do so at a much faster rate because AI is able to increase their ability to produce code (more in line with tech / team leads).
> Engineers are Already Owning the What, Why, and When in Startups
The thing is that they own these things only if there is a space to own it. But the space for such culture is built only by those who know it much better than any engineer in a team, by those who is in charge of it and can build the proper system with intentions (Product Lead/Founder).
I've struggled a lot in situations where I was really trying to own this, be a multiplier, lead the team in this way but the environment wasn't designed properly because even the Product Lead hasn't figured out anything and hasn't found answers to "why," "what," "when."
But when such culture exists, that's an insane opportunity to build a team of multipliers.
That resonates Vasiliy. You definitely need a product vision + set constraints and that comes from the leadership.
Normally, if that's not the case and even the leadership team is confused -> that trickles down to teams as well and we are more or less beng busy building some features but not actually being productive as we are not building the RIGHT things.
In such scenarios, my recommendation is to put your best effort with building useful things and being helpful. At the same time, the other part of being a multiplier (making everyone around you better, should still be the case, so I'd focus more on that side).
And yes, good call on when such culture exists (there is clear product vision and engineers are encouraged to own the full cycle) -> that's a really great environment to be in.
I love this article! I talk about similar issues in my blog. When my colleagues asking if AI will replace them, I answer: “You are an Engineer! Your job is to solve problems with or without writing code. AI is just a tool to help you write code(and make an exploration)”
Glad the article resonated Olena. And yes, well said. Love your answer, we are completely aligned!
The shift from pure coding expertise to impact-oriented engineering really resonates with what I'm seing in the industry. The contractor analogy is spot on becuase it highlights how stakeholders care about outcomes, not just activity metrics. What strikes me most is how the multiplier mindset naturally aligns with AI-assisted developement where the value isn't in writing every line of code, but in architecting solutions and enabling team velocity.
Glad that it resonates! And yes, companies, people and overall organizations care about outcomes, but a lot of times they misinterpret what actually they need to get to the desired outcomes :) And yes, multiplier mindset + AI-assisted Engineering is a powerful combo these days.
The tickets are the leverage, Jira studies what the optimal workflow is for getting things done. So, if you deeply integrate your process into a system that studies the most efficient workflow that is the leverage the ticket pusher can be set up to be the leverage.
There's definitely time and place for that as well. There is a specific Staff Archetype called: the builder, who focuses on hard tasks and going one task after the other. But the focus is on hard tasks and the ones that not many people can handle.
And also of course in regular environments, people who you can trust to get things done within the right timeframe and also quality are important. The problem comes if you are too relying just on pure ticket definitions and clear description to get your work done. Remember, if you can describe the task really well, AI can also handle them (especially low-complex tasks).
Love this, but with slightly different view when I think what always made a great (not good) engineer - one that understands the bigger picture, systems design, extensibility, scalability, reliability, flexibility, etc Those considerations resulted in systems that lasted and scaled. In my experience, using AI to generate code these aspects may have become even more important in terms of how to guide and invoke and course-correct AI code generators that often build exactly what you ask for without consideration for these things unless you explicitly ask for them. It can be narrowly focused, with recency bias, over-indexing on the latest set of prompts at the expense of previous consideration that had been accounted for and now begins to erode. It can also have been trained on masses of code that included good coding practices and bad. As someone invoking it, you need to be able to recognize when bad patterns are being repeated/introduced. Language can also matter here - think of the level of sophistication of the average Python coder vs the average say Rust coder. The code base being trained on in one language may, on average, model a higher level of sophistication than the other. How much attention was paid to the quality of code being used to train the system?
So, yes, the engineer of today must be a multiplier - one that understands architectural and systems design so as to effectively multiply towards systems the will be resilient, will scale, will accommodate new use cases and will last other tests of time.
My two cents, but would love to be corrected.
Great perspective! You are definitely right. Good understanding of system design, and overall good practices are more important than ever. With AI, you can generate code based on your ask, but then how that code fits into the large system, that's what's really important to know and understand.
Based on recent report I checked -> a lot of engineers and engineering leaders mentioned that critical thinking is one of the most important skills for an engineer now and in the future as well. And that's the skill that enables you to really think if the code fits into the system or not (and not just blindly pasting it).
Great write up. And I think the future is Human Centric AI Assisted Engineering.
Fully with you on this. Really like the phrasing of "Human Centric AI Assisted Engineering"!
Thank you 🙏
I really like the idea that engineers are moving more towards product managers / owners. I think AI is really going to split software engineering into two factions: one that is super technical and will be needed when AI coding tools can't get the job done right (deep technical knowledge) and those who understand the code AI is producing it, but do so at a much faster rate because AI is able to increase their ability to produce code (more in line with tech / team leads).