3 ms·
Number one: don’t get hung up on it being a ‘promotion’. You’re playing another, more specialized position, but you’re just one player on the team - not the bos
by jameshart 7y ago
Number one: don’t get hung up on it being a ‘promotion’. You’re playing another, more specialized position, but you’re just one player on the team - not the boss, and you can’t make every decision about how the software gets built (that won’t scale, and if you’re doing that, why do we need all these other developers anyway?)
It’s not your job to tell everyone what to do. It is your job to take the time which developers typically aren’t afforded to learn more about the relevant context of the problem than they can, think, plan, and prototype and bring back and share that additional information you have learned with the team.
The job is, at its heart, to help software developers be able to make smarter decisions.
So the core skill winds up being communication - learning how to understand what the developers on the team are thinking, how to explain constraints and opportunities to them, how to collaboratively problem solve, and how to resolve disagreements among devs about what trade offs to prioritize.
- qznc 7y agoLearn what everybody should know and then tell everybody. In larger organizations (multiple teams on the same product) this might already be enough. Once you have a broad knowledge people will start asking you stuff and then involve you in decision making.
- zamalek 7y ago> The job is, at its heart, to help software developers be able to make smarter decisions. If anything, I've found that it strongly resembles Confucius' mentor/subordinate writings. The mentor is frequently below their subordinate. Code quality/mechanical sympathy is a constant struggle, but my teams are slowly improving. Decision making is less of a hill, my teams are rapidly learning to make really strong decisions (sometimes better than my initial decisions). An architect should aim to teach their way out of a job.