This is still a draft, and isn’t totally nailed down yet. If you have any thoughts about things that are missing, bits that are incorrect, or any questions, please post on the P2 thread! - Ryan
At its heart, Human Made is a technical company: we build things. This involves a number of roles, both technical and non-technical, as well as varying levels of experience and seniority.
Generally speaking, HM doesn’t have a traditional hierarchy, but rather has a relatively flat internal structure. The agency side of the business is split into pools of engineers and project managers, alongside the other branches of the company. Everyone reports to the partners. The agency is split into ad-hoc project teams, which consist of project managers (generally one) and engineers (generally with one lead engineer, who is a senior engineer).
Engineering roles at HM are generally divided into three levels of seniority: junior engineers, engineers, and senior engineers. These engineers work with the rest of their team(s), with the lead engineer on a team being the one responsible for larger architectural decisions, and responsible to the project manager for technical decisions.
Alongside the engineers, the Engineering Director (Ryan) is in charge of setting the direction for the engineers, and implementing this direction. Practically speaking, this involves setting standards, providing tools and support, and acting as a force multiplier for the rest of the engineers. This also involves making decisions where needed.
The CTO (Joe) has ultimate authority over engineering, and is also responsible for other branches of the company, including hosting and other technical products. As a partner, Joe is also responsible for HR and business decisions around engineering efforts and engineers.
All engineers are expected to have a baseline of skills for working on projects. Apart from the basic technical skills, such as being able to develop with WordPress, a number of other “soft” skills are requirements.
Engineers should be able to work autonomously. Given an issue or task with a clear plan, they should be able to work through the issue from beginning to end and solve it. Often, this will involve feedback and discussion, but they should be able to apply problem-solving skills to work through the task.
Communication is a must. The nature of remote work means that communication needs to happen much more actively, as it’s much harder for project managers to spot if someone’s stuck on a problem. Feedback to and with the team is crucial to keeping everything running smoothly and everyone happy. This includes pushing back when a task is unclear, and knowing when to ask for help.
Engineers need to be able to work directly with clients. Client work often requires working with technical teams on the client’s side, and is an important part of the job.
A willingness to learn and grow is a necessity. Engineers should be willing to continue learning as new technologies and techniques develop. They also need to be able to take criticism and apply it constructively, particularly as it applies to a project.
What makes an engineer senior? The difference between the roles is tough to describe, and doesn’t come down to a checklist of factors. However, there are clear attributes that senior engineers have in common.
Senior engineers are expected to have real world experience managing complex projects, and should be able to architect a project, taking it from start to finish. In the absence of others, they’re able to effectively push a project. This includes the ability to work in isolation when needed, which requires strong understanding of the codebase, as well as excellent debugging skills.
Senior engineers are expected to be able to own a project, architecting it based on client requirements, and building the project from the ground up. Often, this includes knowing when to say no. At times, requirements may be infeasible, and it’s important to have clear and direct communication with clients to ensure we avoid surprises.
Likewise, senior engineers should own their decisions. On projects, the buck stops with them. This means being confident in decisions that are made, as well as knowing when more information is required before making decisions.
Having opinions is encouraged. We grow as a company and individually by having active discussions about the direction we’re heading. This again ties into knowing when to say no.
Senior engineers should be able to lead other engineers on their team, and importantly, should be a force multiplier for them. They need to be able to work with the other team members, including engineers and project managers, to lead the technical vision for the project. They should make the rest of the team more comfortable in their work.
Generally, senior engineers should have T-shaped skills: they should have deep knowledge in some areas, as well as broad knowledge to be able to work across all areas they’re involved with. Specialisation allows them to help out on specific projects which require those skills, while generalisation enables working on any and all projects.
Senior engineers also need to be willing to learn. This goes hand-in-hand with being T-shaped, as areas of specialisation may become less important over time, or new projects may require brand new skills. In particular, senior engineers need to be able to dive into brand new fields and come out with a deep understanding. They also need to be able to take criticism and apply it constructively.
Most skills that senior engineers have are around processes and organisation, rather than specific technical skills. It’s not possible to say “just learn X, Y, and Z to become senior”, as a large part of the role involves these softer skills. A lot of these skills can only effectively be gained through exposure and experience in real world projects, and there’s really no set checklist.
There are two main ways for career progression: vertical progression, and horizontal progression. Vertical progression is the traditional model used in many companies, and involves progressing up through a hierarchy. Horizontal progression is focussed on gaining additional responsibilities and skills, and involves a degree of specialisation.
With the traditional model of vertical progression, moving upward causes cases where people who are good at something (like writing code) are promoted out of this, and into a brand new role (managing a team) that they may not be as good at. This can also be limiting, as it offers a single path of progression with little to no choice on what you want your role to be. With vertical growth, the only way out might be to move to another company.
Horizontal growth is about changing or adding to your role instead. This may involve learning new skills and technologies, or working in new areas, such as products instead of agency work. Both of these can improve your T-shaped skills, either by gaining deeper knowledge in an area (lengthening the T) or understanding broader applications and fields (widening the T).
Horizontal progression also allows specialisation. If you really enjoy a certain area of work, you can specialise in it and become the internal go-to person for it. This can involve consulting more, rather than necessarily working actively on the nitty-gritty of the code, or becoming a problem-solver who can jump in to existing ongoing projects as and when needed. Horizontal progression can also allow dialing back to just a single area of specialised focus.
Both forms of progression are available at Human Made. For junior developers, we encourage vertical progression and movement towards becoming more senior. As you become more experienced, horizontal growth becomes more important, allowing you to continue to grow in your existing role, or change up your role while remaining at the same seniority. We have a large range of areas we work across, including agency, products, events, and hosting, and moving to a new focus can offer new opportunities and challenges.
Ultimately, Human Made is designed to be a place you (and we) want to work at, and being able to grow is a part of that. We want to offer you the ability and opportunities to grow as an engineer. Our intention is for all engineers to be at a senior level.
Your developer buddy can help you identify areas of growth and learning, and help you set goals. This includes working out places to improve, and new skills to start learning. If you’d prefer, you can also direct general questions or requests for feedback to Ryan or Joe.
Major changes in your time allocation or role are HR matters, and as such, should be discussed directly with a partner (typically Tom). This includes dedicating time to learn new skills, moving to a different focus, or changes in seniority. Progression is naturally tied to your salary, and roles are also tied towards company goals and focusses. Questions about the technical side of things should be directed to Joe.
We strongly encourage learning new skills, and improving existing skills. There are a number of ways to do this, including community contribution, training, and internal opportunities. (Everyone learns differently, so don’t be afraid to eschew this advice and try other ways of learning!)
One great way to learn new skills can be to work on open source projects, as you get to learn from other people in the field, and work on real problems. These projects provide a great way to work with other people and get feedback, discuss and defend ideas, and work with established codebases. Contributing is especially useful with projects which are immediately applicable to the business, including WordPress core, plugins, and tools. These projects can provide an immense wealth of experience, and provide plenty of opportunities for further leadership.
Contributing back to open source projects you’re using should be considered part of your regular role. This includes filing issues, providing patches, and helping out with maintenance where relevant. This benefits us, as we get increased utility from the projects, and also benefits the wider community with better-maintained plugins. You don’t need to ask before contributing to open source projects, however keep in mind how much time you’re spending, and be sure to discuss with your PM for larger contributions.
Dedicated time for working on open source projects can also be allocated, whether this is part of career progression, or just wider contribution to the community. (If you want to increase how much time you spend contributing, or start contributing to learn, you should contact Tom.) It is important to note that we don’t expect you to contribute to open source outside of working hours, and where possible we’ll try and fit your contribution time into working hours.
Increasingly, we’re also providing more opportunities for training, both internal and external. Your yearly conference budget can and should be used for professional development, including attending conferences outside of your regular comfort zone. Further paid training can also be expensed. We’re also beginning internal workshops and training events, and hope to ramp this up in the future.
Additionally, some client or internal projects may involve new technologies. This is a great way to improve your skills, however it is deeply intertwined with resourcing. If a project like this does come up, talk to those involved with resourcing on your current project, and the one you’d like to move to. Where possible, we’ll attempt to accomodate this, but this isn’t always possible. More opportunities always come along, and we’ll try and remember your request for the future. :)