Software Development Team Structure: Important Roles and Responsibilities(steelkiwi.com)
steelkiwi.com
Software Development Team Structure: Important Roles and Responsibilities
https://steelkiwi.com/blog/software-development-team-structure/
6 comments
The PM motivates developers? I’m quite motivated, thank you.
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).
[1] https://blog.pragmaticengineer.com/what-silicon-valley-gets-...
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-...
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"
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.
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.
An agency that bilks their clients this way should face consequences. Engineers spilling the beans is a weird oversight system but, whatever works I guess.
> 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.
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.
oh wow, this is everything I've ever wanted. I guess I need to go work for an SV-like company.
Isn't separating devops away from developers and into its own role/pillar missing the point?
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.
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.
This was my first thought, followed by the confusing mobile developer's list of responsibilities.
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.
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.
Sometimes, it can be the same person. In a largish endeavor, there may be few SAs, many SEs and even more devs. In my experience, it depends on the diversity of tech that the solution entails. To address your point (perhaps semantically) the SA may see a wider view... business lens, sustainability lens, etc. Often, the Senior Eng may interface a lot sith the SA, but may also hae more depth on the pure technical aspects of the solution. Captain Kirk is the SA, while Scotty might be the Senior Engineer. Kirk dreams of things, and can probably execute, but Scotty can keep him honest within the bounds of physics. Each needs the other. Ultimately, they are names on hats, and as long as the right people are in the room, I will take experience and communication capability over titles on cards. Source: This is what I do daily.
The SA is basically our tech lead in that regard, even though doing more, like strategic items. If we scale up to lots of developers and sub-teams, we’d have dedicated tech leads also being developers.
Regarding senior engineers; we have multiple seniors on the team anyway, seniority doesn’t necessarily put you in an influential position.
We use the SA basically as a technical coach. They are not the boss, and they don’t own the solution or push decisions, we practice collaborative ownership in that regard. I like to say the SA is our development scrum master.
We run like this on projects for banks or insurances. Allows us to execute in an agile fashion (we actually use XP) while still being able to plan months ahead (high level) - those types of customers love their Gantt charts and solution architecture documentation ¯\_(ツ)_/¯
Regarding senior engineers; we have multiple seniors on the team anyway, seniority doesn’t necessarily put you in an influential position.
We use the SA basically as a technical coach. They are not the boss, and they don’t own the solution or push decisions, we practice collaborative ownership in that regard. I like to say the SA is our development scrum master.
We run like this on projects for banks or insurances. Allows us to execute in an agile fashion (we actually use XP) while still being able to plan months ahead (high level) - those types of customers love their Gantt charts and solution architecture documentation ¯\_(ツ)_/¯
[deleted]
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.
The comment section here is the only reason why this should be on the front page.