It’s amazing the overhead the “traditional” or “agency” model brings with software development and how it reduces engineers to developers who just need to execute whatever it’s decided by people up the chain. No wonder autonomy, leverage, career progression and pay are all more limited in this setting. I wrote in more detail about exactly this “backwards” approach and its implications [1]
Compare this with how some of the fat-moving companies work. Instead of 7 different people (from BA and PM and a dedicated DevOps engineer etc etc and all the comms overhead) you have two people / roles:
- Product & design: the “why” and “what”
- Software engineers: the “how” and building/shipping. Note that these people are called engineers for good reason at these companies. While the article says “ A team full of great developers may not bring the expected outcomes if there’s poor communication.” - duh, at places I’m talking about, engineers communicate with each other without a project manager for the most part. In fact, decent comms is something these companies screen for during the interview process. And “DevOps” is part of the role: you build it, you own it. Of course, there would be platform-focused teams and program/feature teams.
These tech companies have other roles for sure: most notably, data scientists and other not-so-technical roles (marketing, operations, legal etc)
But by having one engineer own what companies like SteelKiwi have several people do, no wonder they’ll be able to move faster (less comms overhead), pay more (far more value per engineer) and provide more autonomy (you own solving the problem, not executing the task the BA and PM agreed on, and you’re not expected to understand anyway).
This, although I would call it the 'enterprise' model.
This is how teams in the UK Gov are structured (infact we have more roles [52 at last count]) and its horrible. Aside from the lack of ownership and autonomy at an individual level you also end up with increadibly fragile teams as theres no depth of experience.
If you have 7 people and they all do different things you spend more time finding things for people to do than working on valuable problems - much better to find people with overlapping skillsets in the domain you want to solve a problem then let them get on with it. So if you want to build some software - hire people that can write code, if you want to provide information - hire some writers. Hire smart people and they can do the bits around the edges 'enterprises' think they need specialsists for.
"A jack of all trades is master of none, but often times better than a master of one"
The challenge agencies have to deal with, that internal dev teams don't, is that with a contract software engagement, every conversation between the developers and the customers risks impacting the contract terms.
In an internal software project, when an engineer looks at a problem and realizes it can be trivially solved with an off-the-shelf airtable template, that's a win for everyone! Less code to maintain, less distractions from other more valuable projects, and value delivered sooner.
If a developer working for an agency realizes that, and says it out loud during a meeting with the client, they just undermined the basis for the entire engagement.
> It's amazing the overhead the "traditional" or "agency" model brings with software development and how it reduces engineers to developers who just need to execute whatever is decided by people up the chain.
It's a good approach if you can't attract great talent to begin with. You'll pay lower and have a higher head count so costs are about the same.
SV has the talent pool and the compensation to make it attractive to work there.
One role I recommend having, especially in larger/enterprise endeavors, is a Solution Architect.
When delivering enterprise applications, we usually have three roles running the project; Project Manager for processes/planning/..., Product Manager on the requirements/BA side, Solution Architect on the tech side, some code involvement, focus on the bigger picture.
How would a Solution Architect be different to a senior engineer on the project or a tech lead? Experienced engineers who are thinking longer-term, while also helping team members, and leading by example for planning, building, deploying etc.
I thought this whole full-stack developer stuff was just pushing the traditional role of ops onto dev.
I would argue environmental ops is a different speciality and it has a lot of very specific domain knowledge attached. Its doable but it doesn't feel efficient.
An article on team organization like this that doesn't at least mention https://en.m.wikipedia.org/wiki/Conway%27s_law leaves me suspect as to if the authors have done this subject justice.
[+] [-] gregdoesit|5 years ago|reply
Compare this with how some of the fat-moving companies work. Instead of 7 different people (from BA and PM and a dedicated DevOps engineer etc etc and all the comms overhead) you have two people / roles: - Product & design: the “why” and “what” - Software engineers: the “how” and building/shipping. Note that these people are called engineers for good reason at these companies. While the article says “ A team full of great developers may not bring the expected outcomes if there’s poor communication.” - duh, at places I’m talking about, engineers communicate with each other without a project manager for the most part. In fact, decent comms is something these companies screen for during the interview process. And “DevOps” is part of the role: you build it, you own it. Of course, there would be platform-focused teams and program/feature teams.
These tech companies have other roles for sure: most notably, data scientists and other not-so-technical roles (marketing, operations, legal etc)
But by having one engineer own what companies like SteelKiwi have several people do, no wonder they’ll be able to move faster (less comms overhead), pay more (far more value per engineer) and provide more autonomy (you own solving the problem, not executing the task the BA and PM agreed on, and you’re not expected to understand anyway).
[1] https://blog.pragmaticengineer.com/what-silicon-valley-gets-...
[+] [-] lobsang|5 years ago|reply
This is how teams in the UK Gov are structured (infact we have more roles [52 at last count]) and its horrible. Aside from the lack of ownership and autonomy at an individual level you also end up with increadibly fragile teams as theres no depth of experience.
If you have 7 people and they all do different things you spend more time finding things for people to do than working on valuable problems - much better to find people with overlapping skillsets in the domain you want to solve a problem then let them get on with it. So if you want to build some software - hire people that can write code, if you want to provide information - hire some writers. Hire smart people and they can do the bits around the edges 'enterprises' think they need specialsists for.
"A jack of all trades is master of none, but often times better than a master of one"
[+] [-] jameshart|5 years ago|reply
In an internal software project, when an engineer looks at a problem and realizes it can be trivially solved with an off-the-shelf airtable template, that's a win for everyone! Less code to maintain, less distractions from other more valuable projects, and value delivered sooner.
If a developer working for an agency realizes that, and says it out loud during a meeting with the client, they just undermined the basis for the entire engagement.
[+] [-] 908B64B197|5 years ago|reply
It's a good approach if you can't attract great talent to begin with. You'll pay lower and have a higher head count so costs are about the same.
SV has the talent pool and the compensation to make it attractive to work there.
[+] [-] Quarrelsome|5 years ago|reply
[+] [-] cygned|5 years ago|reply
When delivering enterprise applications, we usually have three roles running the project; Project Manager for processes/planning/..., Product Manager on the requirements/BA side, Solution Architect on the tech side, some code involvement, focus on the bigger picture.
[+] [-] gregdoesit|5 years ago|reply
[+] [-] unknown|5 years ago|reply
[deleted]
[+] [-] jayd16|5 years ago|reply
[+] [-] Quarrelsome|5 years ago|reply
I would argue environmental ops is a different speciality and it has a lot of very specific domain knowledge attached. Its doable but it doesn't feel efficient.
[+] [-] imdsm|5 years ago|reply
[+] [-] NickKampe|5 years ago|reply
[+] [-] hibbelig|5 years ago|reply
[+] [-] ipsocannibal|5 years ago|reply