Software architects should be involved in earliest system engineering activities
insights.sei.cmu.edu
insights.sei.cmu.edu
You want to be the architect and me just a lowly coder? Ok, I'll fix my own compile errors, all other problems are on you.
A friend used to say, "every line of code you write, you make at least one, if not more decisions about the architecture of the program" and I totally agree. So I can still see a really good architect being betrayed by a below mediocre engineering team even if the architecture is sound.
This attitude seems to be the default "holier than though" attitude about architects. I think it's more likely that you would encounter pragmatism when the company culture is healthy. Unhealthy company or engineering team and there's no way to tell whether it would be good or bad
In this case we seem to be talking about huge military projects like GPS or Drones and that there is a divide between the hardware parts and the software parts that might have made sense in the past when the interfaces between the hardware were simpler and software was mostly internal. But now when software is such a big part you need to involve software people earlier looking at the bigger picture from the beginning. It will also drive how hardware will be developed, i.e. what you can do with software will drive how you should develop your autonomous military drone fleet.
> Today and into the future the best way to ensure that a new system's software architecture supports needed capabilities and also system evolvability is to involve software-knowledgeable personnel--specifically software architects--in the early system decisions about breaking up a system into acquirable parts. At this early stage, many software problems are either caused or avoided, and software architects are needed to ensure the latter.
However there are a lots of non-web orientated systems out there; banks, emergency services as an example. I fall into the latter, and have also worked in the former. In those kind of environments we often have an architect (who is indeed quite a talented and hands on coder), but the hairy implementation details of the architect's design tend to be worked out either by dedicated designers, or some other form of implementer (systems administrators/programmers).
I'm usually present at every stand-up. Realistically, the engineers tend to be fairly specialized, not multidisciplinary, and are not up to speed on quantitative engineering, so my role in defending and adapting the architecture is continuous throughout the project.
I don’t attend product teams’ standups , but our engagements run on the order of weeks to months.
We don’t micromanage development or design choices made by product teams. Yes, we review code and make (strong) suggestions, but we leave service teams free to make choices as long as the risk is low and commensurate with the threat model. It’s our job to guide major decisions and, occasionally, advise on the “least-bad” short-term solution, pointing out where, when, and why a re-architecture will be required in the future. Generally speaking, teams want our feedback on design proposals and concepts. It’s a healthy relationship.
Occasionally we have to force teams to reimplement, or block release, but that’s a very rare occurrence.
Unlike many comments on this thread, service teams leave us with pretty positive feedback. It’s very rare that teams leave negative feedback on our design engagements.
This IIRC is not the OP referring to.
My team engages in the earliest phases of design. Holistic security is our priority, but not a limiter for our engagements.
We just used 3-5 contractors to implement Zuora, Salesforce, and Netsuite in "record time". They're gone now, along with the biz ops person leading the rollout.
As an engineer, I feel like I'm eventually going to have to deal with that flaming pile of shit.
When you have developers who understand how to generalise and abstract, then the interactions can often be very simple, and deferring to team leads etc. can work just fine.
Taking part in stand-ups for instance would be a complete waste of time for anything except application architecture and it's only relevant in projects which are using Scrum. Even then, it's possible to do the job by being available (at the risk of missing some unofficial or ephemeral info) and taking part in the sprint review. I prefer involving the team in design decisions and giving them freedom to implement things as they see fit, as long as the architectural requirements are being met.
The usefulness of coding skills decreases the higher one climbs the abstraction ladder. Writing production code for a project is from my POV an anti-pattern unless we're talking application architecture and the architect is only part of that one project, which sounds like title inflation for anything except bigger applications. In my experience there were two kinds of situations where it was worth it to write code: tackling less glamorous, but useful tasks that the team didn't have time for and solving trickier problems that the team couldn't yet work out. Otherwise I expect and prefer mature dev teams which can implement on their own, while I am available for guidance if needed and to ensure that the business reqs are correctly translated and their piece of software integrates properly in the platform.
Personally, I found domain knowledge, connections and social skills invaluable for architecture roles. Technical skills are also valuable, but they're table stakes to be honest.
Well, in construction, you have both architects and civil engineers that never, ever place out rebars or pour the concrete. The architects know how to design the building, while the engineers materialize those designs according to the laws of physics and economy.
So I guess one could ask, why should it be any different in software?
In fact, it's like that in pretty much every other industry. I'm an electrical engineer by trade, and even though I know how to practically do the work myself (since I worked as a electrician apprentice before college), it is something that I never touch - nor have to touch. That's what electricians are for.
Exactly. And that's what developers are for.
Since the software world does not generally work this way, we could also ask why the architect/brick layer model should be applied in this world. The decider/implementer model might be a common organizing principle in other industries; that does not mean that it's useful to software.
Brick layers cannot manipulate more than small chunks of a building at a time. Software engineers in contrast can perform the equivalent of turning the Empire State Building on its head.
Software architecture is difficult to get right and too important to leave to one or two senior folks who may or may not have the insight required to make the right decisions.
The architect absorbs vast information and designs a solution, the builder makes it into reality, often making meaningful and lasting decisions during implementation. Both are competent and valuable. Sure there are design-build people and teams, sometimes they work very well. Architects will always have more context in the realm of ideas, that is the space they occupy. Builders have the most context in implementation, and may detect issues that make the whole plan invalid. Collaboration helps. Mistrust doesn't.
Architects don't have to swing a hammer to know where the planks should go, but boy it sure does help if they have.
It helps to do building. I recently took over the ownership of a small component in our system myself. That was the first time I wrote a unit test in our project. Finally I know how our testing and coverage infrastructure is configured.
> The greatest architectures are the product of a single mind or, at least, of a very small, carefully structured team.
In a big project, I would rather relief the one or two architects from their coding duties than to have four or more architects. While it helps to do the building, there are more important things for an architect to do. For example, I'm the one who has the overview of cross cutting concerns like logging and safety.
Disclaimer: I believe there is a big difference what "software architect" means in IT/cloud/web in contrast to embedded/safety-critical/real-time. Most of the complains I hear are about the IT ones (often called solution architects). The article and also my work is in the later category. The methods are nearly the same, but regulations in the later category force the architects to focus on much more details. Maybe that helps to stay more grounded. We do have a similar acrimony with our "system architects" though.
The architect has some grand high level artistic design or dream. Engineers and contractors turn dreams into reality.
Architects have ideas. Engineers and contractors are incapable of high level thinking or having ideas of their own. It's pretty impossible it's like architects are born with it. Sort of like how a CEO is able to have a vision. Engineers don't know how to dream or have visions. It's the job of the architect and CEO to direct us.
Software Architects are not the only way to get software architecture. They may even be the worst way.
"Software Architects who Code" often do not suffer from this issue, depending on how much they actually get involved in production software and operations. However I would struggle to define a meaninful difference between a "Software Architect who Codes" and a sufficiently "Senior Software Developer".
- the good, hands-on, full-of-wisdom senior engineers, whose relevant experience and strong vision enable an entire floor of developers to build the right stuff and quickly. These guys made commits to high and low level code, from network debugging to interpreter design. Really inspiring people.
- The toxic “ideas guy” “architects” who believe it is their job to write white-papers on how everything should be, without providing any guidance on how to actually get there. They believe that all problems would be solved if only we had the right perspective, even though perspective can’t be executed on x86 architecture. These guys constantly made me wonder why they were there and what they did all day.
It is usually easy to identify architectural decisions. You can then find out who made that decision and thus figure out who is the architect.
For example, in a web project: Who decided to build microservices vs a monolith? Who chose the database technology (PostgreSQL vs MySQL vs MongoDB vs ...)? Who chose the cloud platform? Who introduces external SaaS products? Who split up the big thing into pieces for different teams?
You have two classes: management and individual contributors, when there shouldn’t be. Management ought to be able to solve any problem people they serve (i.e., their underlings) are facing, given certain amount of time to familiarize.
It works if they know they are out of touch and trust their people. On the other hand if they try to give input but haven't coded in 10 years it's bad,. Last year I had a fight with a manager who insisted that we use JSON for everything. I pointed out that this is a minor decision and really not very relevant. Another guy agreed and was almost kicked out of the project.
It does lead to a lot of "Black Triangle" [0] situations though. Where you spend a long time with no "real" actionable results to show management, and then after an annoyingly long amount of time present what looks like an insignificant joke to a non-programmer.
I understand that many large institutions are constructed in a mechanism you describe. In many cases, these managers are technical enough that they can substitute any individual working under them. There are also many cases where they are not sufficiently technical.
Nonetheless, if a manager’s purpose tailored towards prioritizing, fighting for projects, and assisting ICs career growth, I am not convinced that that manager is necessary as I am not seeing his value. Prioritization ought to be intrinsic for everyone and is more a collaborative choice, no? Why does a single individual (manager) decide priority?
Often ICs don't have the context necessary to contribute much to the conversation once it leaves the sphere of influence of the team they're on--and more importantly most of them don't want to acquire that context, often because they view it as inferior work that is beneath them. They don't see value in management because they can't see past their own egos and myopia.
Plus, at the end of the data, a good manager should aim to hire people smarter and better than them. If they can step in for those people quickly then they're not hiring better or smarter people which is a problem. A first line manager should understand what people do but that is different from being able to do their job to the same level.
Somewhere, in a different forum there is a bunch of managers discussing an article where a project has completely failed because some completely naive engineers made a bunch of rookie management mistakes, pissed off half their employees and crashed the whole project.
And they are busy saying "Engineers who don't know anything about management shouldn't be managing stuff..."
Management is not something complex. Almost all of management is expectations management.
Your comment probably applies for a team lead with a half dozen IC reports. Add in one other layer (i.e., a half dozen team lead reports) and it might still apply in some cases. But double that number or add in another layer and things are probably far beyond the scale you were imagining. The manager’s job now requires a vastly different toolset that most developers know nothing about, have no experience with, and generally wouldn’t even know how to think about.
I disagree with that.
If your manager has the best technical skills of anyone on the team, then they are probably a poor manager who can't hire/retain good technical people (by far the most important job of a manager).
As far as skills go I expect to maintain my coding skills and as far as what I know more about than other SE's is not about skill as much as it is about practicality of time spent. We need the devs to be writing code/implementing every day and the architects spend more time on the, well, architecture as well as business interfacing and planning side.
So that's basically it, the difference is where we spend our time and focus. It's more about roles and needs of the group than about the skill set. At least, that's what I'd hope. Anyone thinking they are a Senior level engineer who can't understand the concepts of software architecture needs to rethink their position and maybe broaden their skill set a bit, imho.
The most common issue in my experience is Software Architects who don’t spend ~10 to 25% of their time actually working with the code base are largely ignored. You get things like two layers that are both 100% 1:1 mappings of the layer below them.
It’s not about coding skills, but software is complex enough people quickly lose touch without regular feedback. Resulting in people spending a lot of time solving non problems.
You get layers that are 1 to 1 mappings from engineers? Gee only software architects have the innate ability to notice an issue like that. An isomorphic layer more than likely exists as a translation layer to make composition with another layer easier even though entities are bijective.
So you think an engineer is unable to comprehend anything about a layer that is basically an identity morphism in disguise? Wow. Please tell me about some other architect things that an engineer is unable to comprehend. I would like to learn more from great architects who have super powers like "big picture thinking"
Anyway, I worked for the same company and very occasionally helped some friends on the team, but was not really directly involved day to day or even most months.
I don't have context on what those programmers did, nor do I know whether the 8 layer server side design was good. But I do know that how good a design is, is not influenced by a PHD or a software architect title.
That being said, an 8 layer design points to 8 things that want to be re-used. Typically you just need 3 layers (letters represent types, arrows represent a conversion process from one type to another.):
IO input -> A
A -> B
B -> IO output
IO input -> A
A -> B
B -> C
C -> D
D -> E
E -> F
F -> G
G -> IO output
Likely the architect and the software engineers both don't know what they are doing.
I'll go further to say that no architect will ever reason about "layers" the way I just did because my break down of the design layers above isn't some science. I made it all up, it's basically my opinion and most architects you meet will have either canned opinions from some book or have their own made up reasoning on how it all goes together. An engineer can easily come up with his own opinions and read an "architecture" book as well (which is again basically reading someones opinion). The "architect" title is a BS title that implies an "architect's" "opinions" are better than an engineers. It's not and from what I've seen in the industry an architect rarely has better design chops then an engineer. It's all relatively equal.
That being said there is some formal theory on network topology and graph theory that can say something definitive like this graph has faster output than another graph but rarely is it used or applicable in most web apps.
I'm interested in whether you think this could be the case even when compared with say a development team designing the architecture as they go.
As yet another data point, the website cannot handle Saturday HN front page traffic. How can "Principal Systems Engineer" meaningfully talk about such complex matters of system design and architecture, when they fail at much easier task of handling web page availability with a slightly non-trivial load?
EDIT: A few people mentioned that it would be incorrect to use `HN hug of death` as an example of author incompetence, since it was just some random university or institute. I was about to agree, but then I checked the website, which proudly stated: "The SEI: The Leader in Software Engineering and Cybersecurity". From my perspective, if you claim a thing like this, you definitely should be able to handle a minor spike in traffic.
Now, it also might be that author has nothing to do with the organization and hence not responsible for the website performance. However, this is also not true: "<AUTHOR> is a senior member of the technical staff and Principal Systems Engineer at the SEI...", as stated on their bio page. To me this either shows little ownership or little understanding of underlying resources the author relies on, which serves as another proxy of their actual architecture skills.
C'mon, this is a university's website, and the author of the original piece is just a user of that website's CMS, not its architect.
A _good_ software architect is almost the exact opposite. She's a minesweeper, finding obstacles that would have caused re-work and scope change. She untangles the business requirements so that expectations can be clearly set and communicated. She does research on existing approaches to the problem, becomes acquainted with the relevant open source work and thereby serves as a check against "not invented here" syndrome. If this some of this ends up being best delivered in a document or a diagram, so be it, but the point is to enable the developers, not a masturbatory exercise in self-indulgence.
Who is responsible for understanding the interconnections of a system when there are over 100 engineers? That's the architect.
1. Are you sure that the person writing the blog post is the person in charge of webhosting?
2. I have pet projects running on some small virtual private servers. I have no idea if they could handle the load from HN. Does it make me a worse software engineer that I can't justify paying more for a beefier dedicated server right now?
PS: does someone have an estimate of how much traffic (hits per minute/hour) the HN front page can bring?
(he got 20K/day, which for all intent equals zero in my experience)
You do understand that this is cmu.edu, and the blog post is probably written by a CS prof who has nothing to do with CMU's basic IT operations.
If our "Software engineering leaders" cannot handle simple tasks, what does it say about our profession?
It says that they have more important problems to be working on than managing their university's web-servers, which a CS undergrad could do.
They’re so busy with their “more important” issues, that the whole thing fails in practice.
If they truly had organizational wisdom we could utilize, why don’t they deploy it themselves, to keep their website online during small spikes in traffic?
If their work can’t even be applied to their own organization successfully, why should we believe it will be successful elsewhere?
“Physician, heal thyself.”
This is such a weak argument. Where did you hear that their principles were not being applied in real life? Why do you automatically assume the university's website is built on their principles? This entire discussion is trivial.
I find it hilarious.
Secondly, you can't know he hasn't worked on mature systems (he didn't say). Most people learn by working with a variety of systems that are at different stages (greenfield to twilight), and more importantly with different quality (poor versus good architecture/systems/teams).
A long period working on one good system may help a few people learn, but from what I have seen, it often doesn't (I have worked with crap programmers on mature systems).
Hopefully GP answers for themselves.
You're describing a problem caused by developers, who for some reason ignore the architecture that they are supposed to adhere to.
Depends on a type of project and many other factors. If you're say building a business app for a client delegating architecture decisions to individual devs on "as-needed" bases means either that all members of team need to be equally capable, have an excellent understanding of client's business and very clear and uniform vision of bigger picture where project is going - or more commonly that you'll end up with a terrible, suboptimal mess of different approaches and interpretations of requirements. Also you usually don't want to pay 10 expensive devs to study the client's business and specifications for days or weeks, when you can have just one do it and propose the solutions to others. So you need a person in charge, and you need that person to know how to do it good, because not everyone, even senior devs, is equally capable of tracking all the moving parts and envisioning the optimal solution. It's a job for someone who's good at it, and you can call them architect or tech lead or whatever, title doesn't matter, but letting them be focused on global picture instead of doing little isolated tasks with everyone else will save you a lot of headache.
However, I totally agree with you that often people hired to do that are not really good at it, just like a lot of managers are not very good in managing projects (and many devs are not very good in programming I guess). The problem there is not with the role itself, but HR and the organization.
Imagine doing all that by letting thousands of random developers run completely free. I mean, I don’t have to imagine because we didn’t actually involve architects early enough, and it’s cost us billions to correct that mistake.
The author is talking about large defense systems like satellite arrays and airplanes. The status quo that the author is responding to is that engineers of the physical systems (missiles, satellites, etc.) make all the decisions with software bolted on after the fact. This is definitely true at places like Boeing.
You could replace architect with "senior software engineer" or whatever.
Point is, software should have some seat at the table during the design process.
The fundamental thesis of the piece is: "If, instead, system acquirers ensure that systems engineers address software concerns at the same time as the physical solution is conceptualized, acquirers can opt for a slightly different physical system, whose software architecture is tuned to optimize the provided capabilities."
Which, to me, sounds entirely reasonable. If some system needs an MLOC or so and the software will be doing a complex thing like piloting the aircraft, you better be thinking about the software from the beginning of the project...
I think this applies to all disciplines “under” systems engineering too, the thing is with software there are often a lot more chances for things to go sideways compared to EE or mech in development.
The sooner you get the smart people in each discipline (Software or otherwise) to the table the better off everyone will be. This is why in systems engineering processes like ARP4754 you’ll see the word “preliminary” a lot. Preliminary architecture can be developed along with the system requirements as a basis for discussion with those performing the safety analysis and those implementing the software and hardware items. Having a software architect at the table, someone who can reason about the software architecture and its impact on the systems as a whole and the safety case can only help.
Someone should just change words to "hardware people" and "software people" and I think people here would receive it better.
If you have one "squad" that owns the product top-to-bottom ("squad" being defined here as a team with daily discussion and syncing of progress) then I think the architect aspect is decentralized across everyone.
But once there's more than one "squad" that each own a separate chunk of the overall product and the work of these squads overlap even a little bit, then there must be one individual who is enforcing a confluence of design in that overlapped region.
> organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations.
Usually the key implementor architects software. Even in a large complex system, you really want key implementors working together to design.
If it's a single piece of software that runs on one or a few machines, sure.
But the OP talks about complex, distributed systems that run on several different hardware architectures, and probably implemented by several dozens or maybe hundreds of software engineers. I think you really need an architect for some key decisions: where does what kind of data come from, where is the source of truth for which data, what protocols are used for communication between them etc.
Maybe that's more of a system architect than a software architect, but the lines are kinda blurry.
It takes a lot of "tribal knowledge" about the various teams involved in a project to do this kind of thing well. The most successful architects I have worked with are the ones who have a lot of experience at the same company. They don't design the architecture -- they convince all of the participants in a project to collaborate on designing the architecture.
> They don't design the architecture -- they convince all of the participants in a project to collaborate on designing the architecture
They might also have difficulty ensuring that architectural constraints which are not directly visible to them are respected.
So yes, a dedicated role is needed.
Something that people really need to understand when they are asking if something is done. “Done enough for now” is the best, simple phrase I’ve learned to convey the sense of what was quoted above. It can easily segway into that conversation, if handled delicately, and teachable moments for management.
How do you convey doneness in your projects?
2) You "do" every use case end to end (including the pieces of infra needed for that use case and the user interface parts).
3) You add regression tests (unit / func) for the use case.
4) Every new such use case is a new release.
This way you are always done.
The real risk of working UC by UC, is that you might get locked into bad architecture.
The way to mitigate that is by using microservices.
I love the "done enough for now.," although I do find some use in breaking down doneness.
My levels of done:
1) I've got a prototype or POC that works. I've cracked the hardest issues and gotten it to work, at least in some way.
2) Code is buttoned up, checked in, and running in the build (probably in a branch), maybe even reviewed.
3) Code is tested, and tests pass
4) Code is integrated and working functionally as part of a system. People are able to call it and rely on it. Proves code does what it needs to.
So I really try not to say "it's done," but more where it is at in this SDL.
* code checked in
* tested
* documented
* deployed
* accepted
For each user story. So performance, capabilities, and other enhancements or fixes are their own user story and follow the same path.
It could be that the available data and current approach yield only 63%, in which case the user story is being worked on indefinitely for months.
Or it could be that 65% is achieved, but the threshold chosen was a wild guess; business value is actually linear all the way up to perfect, so it's worth iterating indefinitely.
The scrum & user story format work well for small and unambiguous units of customer-facing behavior, but some software is made of more than that.
What is the role of architect in the real world? In some high profile cases they are designers - even to the point of doing something like project management/business development (the only reason we funded this project is because of the awesome ideas we got from the architect, we worked with the architect to make sure the building would meet our dreams for this project ...). But more commonly — I understand their role more in construction to me more in the realm of being a maintainer of documentation — maybe they have some role in proposing the original design but the majority of their time is probably spent ensuring that these plans satisfy all required regulations — and updating the plans in response to what actually happens during building so that the building itself will pass all regulations ...
This is nothing at all like the nebulous responsibilities generally associated with software architects. Some projects could benefit from this level of book keeping requirement — but a lot of projects which contain “software architects” probably would reject paying someone to maintain specifications to a similar level of accuracy as is required of real world architects — especially if that was basically all that was being asked of them to do ...
So all components need to be designed and maintained with a high degree of visibility and ideally direct cooperation.
My impression is that the core structures of these contracts are always flawed. For example, they seem based on detailed pre-estimation and fixed fees. To me it would be more realistic to give ranges and focus on core goals and milestones with the expectation that detailed requirements will evolve.
But stepping back even further, the paradigm that drives all of this which is labelled as "defense" is quite an outdated paradigm. So expecting operational aspects to make sense might be asking too much. The paradigm goes back to for example https://en.m.wikipedia.org/wiki/Roman%E2%80%93Persian_Wars
What you need instead is developers on the team who also understand software architecture, and implement it especially in it's initial phases.
This takes more senior developers, then later on less experienced developers can jump in once the structure is in place.
But a completely separate person external to the development team, which is going to define the architecture using text and diagrams only?
That doesn't exist, it's a myth. What ends up happening in practice is that some senior developer on the team ends up implementing the actual architecture, and those documents are used just as broad guidelines at most.
Even if a senior developer ends up "implementing the actual architecture", if that does not mesh with the other subsystems and the other stakeholders, their conflicting requirements, and their weighting of the architectural quality attributes, and so on, the end result misses the goal.
Details become more concrete the more closer one gets to the developer. Conversely, if one goes the other way, things become more abstract. You need people for the topmost abstraction level, people in the middle levels who understand both the abstract and the concrete, as well as the people at the lowest abstraction level where the implementation happens.
Of course, sometimes the systems are small enough or well-defined enough so that the person in the middle level can be the same as the highest-level keeper of abstractions.
I don't think having a separate role of an architect is always counter-productive. The architect as a separate role can be useful: that person listens to other people and teams and filters and translates their desires into something which can be defined unambiguously to be actually implemented. If the architect has time to code too, that's great. If not, then there must be those senior developers who can create the more technical parts and write code, too.
As far as I remember (first read through this week and big parts of the book is stuffed with quotable material) he says that
- that the architect should be able to provide an example implementation
- but that it is also important that the architect steps back and stays away from the actual implementation
I've more or less already decided to re-read that book.
Highly recommend and available in searchable selectable PDF form from archive.org
What my team calls “architecture” - the decomposition into services and classes, database schemas, interfaces between major components - I think Brooks would call “implementation design.”
It seems to me that he would think interfaces between major subsystems would be architect level while any database table that only gets used within a single sub system is implementation level.
Trying to be careful as I realize HN is the kind of forum where he or a close friend of him might show up to correct me :-)
Rather, the people doing these activities should have a solid background in software.
If you don't have software kung-fu, you shouldn't be designing something that will be heavily programmed in order to fulfill its function.
But you can't fix that, so I'll chime in.
In my opinion, an Architect is just a role that gives advancement opportunities to individual contributors that doesn't go down a management path. You're still a part of the dev team, and you still do work.
When I've been in that role, that's how I treat it, and it's worked out pretty well. Generally speaking, when the position gets treated that way, I'd get involved in new products or major changes. For major changes, there's a specific thing we're targeting that needs something different. An extra complexity or just a different approach. That's all I focus on while writing the design document in response to the requirements document. Everything else is fine, but we need to do this one specific thing differently to make it work better. And this will have trickle-down effects on the rest of the system that's going to have to accommodate it. If I've done my job well, those are reasonably doable without that much explanation. I'll write the prototype that gets at the core of what needs to change, do code review with the team I'm eventually going to hand it off to, and explain my decisions in person. Once everyone is on the same page and gets what we're trying to do, I can hand it off and move on to something else.
For new products it's a little different. We want to make sure that we learn from our past wherever we can. Companies often have themes to their products and even a completely greenfield project isn't totally different from other stuff you've done. There's lots of stuff floating around that isn't great, but it's not so bad that you're ready to invest in a "major change." But if you had to do it all over again, you would do it differently.
That's what you want to make sure you capture when you start a new project. So again, there's requirements. And again, I write a tech document that represents my interpretation of the specs as it applies to the systems in play. The vast majority of these don't really matter, and any competent developers on the team can handle them. So my input is to focus on the things that are non-obvious and caused problems for us in the past. But the end result is the same: I write the prototype, workshop it with the team that's going to be taking it over, and hand it off and move on when everyone is confident that we all know what needs to be done.
Sometimes, it's not either of those things. Sometimes there's just a really annoying bug that needs tracking down and is really hard. It might not even be caused by the system your team is working on. You might need some cross-team investigation to figure it out. Sometimes you need a wider knowledge than a specialized team has. And sometimes it's just because some shit is broken that you wrote 6 years ago, and no one noticed until now because no one used it quite this way back then, but now everyone uses it that way, and it's awful, and half the reason you got promoted to architect is because that solution was mindblowing and novel, but now it sucks because no one knows how it works. Not even you. So it's your problem, genius, so go fix it. And you go crawl in a hole of shame.
Architect as anything other than really super double senior engineer doesn't make sense to me. Architect as an outside hire doesn't make a ton of sense to me. Architect as a layer of management that's not engaged in building software doesn't make any sense to me at all.
Architect makes sense as a retention strategy. It makes sense as an upward path for ICs. Architects should mentor. Architect shouldn't be a special title. It should be a normal result of doing solid work over time by a person who wants to keep doing solid work instead of switching to management track just to justify a raise/promotion.
Just my thoughts.
At some places they are also responsible for coding (this also depends on seniority), and at many smaller startups they will also play the role of product/program manager since the companies haven't hired for those positions yet or are not even aware of what those positions are.
I can't comment on specific cases, but I think most engineers are wildly unaware of just how much work it is to play politics at any company, and it's an unspoken part of the job for any manager.
Ps. Im not neglating some parts of the work they do. Simply comparing it to the amount of knowledge that is required in other parts of production chain.
For example, a project manager's role is to track progress of a project, reveal and resolve deadlocks (A waits on B, B waits on C, C waits on A), communicate progress to the outside and so on.
In other cases, managers act as proxies for teams. If you want something from a team, nobody expects you to talk to all 12 members and convince everybody -- instead you talk to the manager, and the manager then talks to the (relevant parts of the) team.
From the team's perspective, a good manager shields them from most of the company's politics, declines nonsense requests early on, organizes all materials necessary for the team to work etc.
In general, managers are paid well because they carry a lot of responsibility. Even a brilliant team will underperform under a terrible manager, and a very good manager can bring out the best in teams.
I’m friends with a architecture manager at one company in Austin that has 4 direct reports, attends a few meetings a day, spends his downtime doing online courses prepping for the next job change, all while making 145k/year.
My manager at a previous company had coding responsibilities in addition top 15 direct reports and was really overworked.
Perhaps you mean talking to recruiters to about hiring more resources for a project ?
Figure out what to do, figure out what not do (10x more work), handle hiring/firing (both are really hard, but in different ways), handle random human situations with employees, motivate the team, get people to grow (give them incrementally larger individual responsibilities over time), get developers to focus on stuff that actually matters, manage the technical debt, plot a clear plan forwards. Feed developers with tasks, suitably small or large depending on their XP level. Learn exactly what kind of tasks each individual can handle. Pre-chew medium-hard tasks so that the can be handled by junior devs. Follow up on tasks, especially those that have an architectural impact. Create product progress. Manage issue tracking. Be on top of devops. Do some random small dev tasks yourself so you don't lose track of the code. Run regular team meetings. Etc. It's an exercise in time utilization/fragmentation.
On a typical day a software manager does work their boss assigns them and answers your questions/queries from other departments.
- Provide status updates to bosses. Reports / presentations in regards to department goals. - They watch over the developers/leads make sure they are productive / issues handled - They attend other department meetings, vendor meetings - They read over everything and provide signoff - They attend community events and represent the department
Every place is different. A manager could be a lead and expected to jump in and code. A manager could be an office manager or a project manager or a product owner as well.
Does that help? They manage the department.. ensure resources are in place.
One of the crappier roles. Very little power, low respect from above or below. Slightly higher pay in general but not uncommon to be the lowest paid in the department.
Give your manager a high five once in awhile. They do a lot to make your life easier.