- Experiment and learn
- Drive tech alignment across teams and orgs
- Focus on the key decisions
- Kill stupid things early on. If you fail at this, you essentially fail at the job
- Be the eyes and ears to look around corners… we’re shipping some product X. We have product teams, TPMs, software managers basically a small army of friction: competing priorities, territorialism and empire building, and then the doers who you really need to help make this product happen. Are the right people working in the right problems? Are we solving them in an efficient way, using the right tooling or tech?
- Partner up with the other passionate people in management. Define the tech vision and architecture so devs can continue building without burning out or running into stupid obstacles that demotivate them
- Help define the culture. Mentor. Figure out what people are good at and advise the managers on who is best suited to a problem: function of their skills, growth areas, need of business, etc
- have strong opinions. Don’t sway with the wind.
To summarize: your focus is resounding impact. Sweat the details but only the important ones. If you need to learn a language or how something works, do your own research and go consult with other smart people in the space. Don’t pretend to know things you don’t. Be up front and ask a junior person to help you make sense of what it is you have, why are things the way they are, and how we got here.
As a freshly promoted staff engineer I am also interested in some more details, because it is not easy to find some good resources on this topic.
> Kill stupid things early on
Can you give some examples of stupid things?
> have strong opinions
This is one of the things I hear a lot, but again, what are those, any examples? My opinion could be wrong and I can't keep it strongly, especially when surrounded with smart people.
The way you kill such things is 1) by telling the truth about how much it's going to cost to do, and 2) by asking for evidence that the idea will pay back the effort required. (I mean, to some degree all development is done on faith that there will be a market there. But an idea that will take 6 months for the team needs a more solid basis than an idea that will take an afternoon for an individual.)
You are making 2 hardest questions sound easy.
1. Sometimes you need to seed optimism to get buy in and sponsorship, even though it might cost higher.
2. Not everything pays back in short term. Of course product team might care about 10% increase in revenue in short term, but 10x idea might disrupt them. That's the reason Blockbuster lost to Netflix, Rackspace lost to AWS
This is obviously stupid, my gut feeling says OP wanted to say totally different type of stupidity, because your example not only stupid thing, but complete incompetence of how products are delivered, unless those 3 people are willing to pay 30B$ each.
“We see a need to build X. Its fancy and shiny new technology. It is right thing to do. What problem does it solve? Dont worry about that. We are going to strong arm a few teams to adopt this, even though it costs money to build and support. Sure, we can make investment in Y instead but dont want to because solving Y doesn’t let us increase head count or write promotion documents. Plus, X is very complex. It guarantees job security for people who understand it. Let’s not worry about what happens if these people then quit and make this thing everyone elses problem”
Its not always outright nefarious reasons but there’s always an incentive structure incentivizing wrong behavior because it benefits individuals or is cool or fun thing to work on, without having meaningful impact or business value
X department (usually marketing/sales) is asking for Y thing without understand that Z thing is actually the thing customers want to solve their root cause.
You have to stay on top of the 'signal strength' of feature requests. If one customers asks for a thing then okay maybe note it down. If 10 customers ask for the same thing ASAP, then clearly go make it a priority to go build the thing.
> have strong opinions
Being a subject matter expert / domain expert you can start to see an understand the 'shape' of the market, the customers, the problem being solved. You get a sense of the how/what/why that will really be impactful.
Some products are built with huge leaps forwards that 10x the previous experience. Others are build with 1000 tiny improvements that make for a delightful UX. Both are equally valid.
Having strong opinions means balancing those two operating modes. Figuring out when to bet big/when to refine/when; when to say no to little thing #342 because it's actually not helping anything.
Wisdom I got many years ago from an old hand was to run this thought experiment:
* An HTTP request
* A business object
* A database transaction
That's web architecture, more or less. Someone requests something and your programs mission is to find that something as fast as possible. In some cases Rails is a great fit, depending on the constraints. Under different constraints Go is the right solution.
When learning the new technologies the key is understanding what problem that technology is trying to solve most optimally.
Additionally, what really separates a "Senior Software Engineer" from the levels above is understanding that after a certain point, technology is irrelevant. Social factors drive decisions much more than technical considerations (Conway's Law).
* An HTTP request
* A business object
* A database transaction
That's web architecture, more or less.
I disagree, IMO the fundamentals are: Naming Things, Immutability, Idempotence, Behavior/Workflows/Transactions/Business Processes, Distributed Systems, Cryptography, Algorithms and Data structures, etc.
In addition to technical fundamentals, there are people fundamentals/soft-skills.
All of these things are footnotes and implementation details to what I wrote.
HTTP request and database transaction[1] are examples of the specific protocols/technologies, and not the fundamentals.
--
1. I guess RDBMS/SQL transaction b/c that's what people usually mean by this term.
* An HTTP request
* A perl script (or C binary)
* A database transaction
Things like DDD exist to assist humans, not computers.
EDIT: in place of "database transaction" we might also say "reading from persistent durable storage" (like a file system).
2. Everything exists to assist humans, even when assisting animals and inanimate objects;)
It was only relatively late in my career that I started to learn and think about the basics. The real world has an surprising amount of detail and the software tries to simulate the real world. First I studied the actor model, then agent-based modeling, then domain modeling.
The most important thing (to me) when learning a new technology is learning what it _can do_ in the most complete way possible. Reason: when I invest into learning a technology, afterwards I want to be able to quickly pick the feature that is most suitable for a particular need without the risk to reinvent some kind of wheel in a dumb and costly way. And for that I must have a mental map of all the features, at least superficially. Everything else you an look up. (The same principle goes for the total of all the technologies I have learnt before).
In practice I make sure I scan _all_ the documentation for the product and build a cheat sheet of the features, concepts, configuration flags, best practices etc. I will consult the sheet later, but the process of building it helps immensely to construct the map of _what's possible_ with this thing.
A recent example - I had to design a GCP solution while not having much experience in GCP. I sat down and browsed the introductory docs of all the hundred plus (?) products that GCP offers, and built a cheat sheet categorizing the features and intents of each and every one. This took me around two days, and ultimately of in the solution I only used a handful services out of the hundred. But these were exactly the ones that solved the problem, including a couple of exotic ones that I wouldn't have guessed even existed.
For the cheat sheets I use Obsidian which is excellent for this.
On which case I expect being offered enough time and training opportunities.
Otherwise the languages I know are more than enough, what you need are soft skills, domain knowledge and architecture design.
Getting yet another way to write the same algorithms is kind of focusing on the tree instead of the forest.
But from your question I get that you need to be able to get a rough estimate how much time it will take to learn the specific technology. And if it's too long, maybe abandon the idea altogether. It's especially relevant if you're doing it part time or after your main job.
-- Use Repl to try examples in the doc
-- build side project