Many businesses (old and new) have a very hierarchical approach to in-house engineering teams following the example of Microsoft and Adobe. This typically leads to teams of followers that are risk-averse, inflexible and difficult to scale. But there is a better way, one embraced by companies such as Spotify, of using agile teams created dynamically for each project.
The Pitch
A more dynamic approach to engineering teams would be not to hire managers, but to hire solution architects. These persons have skills that allow them to be given a brief project description - or even come up with an idea themselves - and they can then independently do initial scoping, research and planning for this project. They can identify the users, appropriate technologies, rough ballpark and key research points or questions to ask. All of this is assembled into a 15 minute project pitch for the key stakeholders to approve.
The Research Team
Once the pitch is approved, the solution architect will assemble their research team from a pool of available team members. A typical research team would have the following members:
1. Copywriter
While they are not engineers and usually do not have any hands-on development experience, they are able to understand technical terms and explain them to non technical persons. They are also capable researchers for non-technical matters such as market research and user interviews. It is their role to write out all decisions and insights from the team in the solution architecture document.
2. Business Consultant
It is this person’s responsibility to provide insights and do research on all business matters. This includes finances, legal and compliance. They can add appropriate risk margins to estimates and calculate operational and other non-development costs. They can also research and write business cases for each requirement and ensure that there is an ROI - this can be productivity, revenue, efficiency, etc.
3. One or more Technical Specialists
These team members have extensive experience and deep knowledge of the technologies identified by the solution architect for the project. They are able to turn user requirements into technical specifications, design infrastructure and databases and create detailed and accurate estimates for all tasks.
4. Designer / UX specialist
A designer is essential for any project with user-facing interfaces. They are to provide user experience insights during scoping and, once the requirements are known, they are tasked with creating interactive wireframes for every interface of the project. These are essentially complete designs but without any branding (colours, specific icon designs, etc). This allows stakeholders and users to focus entirely on the functional aspects as proposed, instead of being distracting by colours and minute details.
Solution Architecture
Once the research team has been assembled, they research and document the solution architecture in detail. The goal of this document is to cover every angle of the project, answer every question, mitigate every risk and leave nothing to chance. The project estimate included in this document should be within 10% accuracy.
Once complete, it can be presented to the stakeholders for their approval. Budget can be assigned and any buy-ins are also secured at this point. Projects can also be considered “not recommended”. If the research points out that there is insufficient ROI or challenges that cannot be met the project may not continue. Valuable lessons are still learned and documented for future reference. Importantly, with this approach, almost all projects that would have failed during development are identified before development even starts. Saving significant cost and time.
Implementation Teams
After the project has been approved based on the solution architecture, the technical specialists from the research team will then assemble their implementation teams from a pool of developers, testers, freelancers and vendors. The specialist will be heavily involved with their team and fulfill the role of scrum master. The solution architect will fulfill the role of product owner and update stakeholders as needed. It is generally recommended to pair each developer with a reviewer. These are second developers that review the main developer’s code on a weekly basis. This has three benefits:
- You always have a backup developer who is fully familiar with the code
- You have a second pair of eyes on the deliverables to ensure security, quality and efficiency in the code and to ensure all code is fully documented and easy to understand.
- The main developer has a sparring partner to bounce ideas off
As per agile methodology, testers should be involved with development from the very start and not only once development has been completed. Automated tested through unit tests and tools is also a must.
The research team is dissolved once implementation starts, however, the solution architecture will high-level monitor the project throughout implementation. They will be available to support with any major changes and can bring in the research team members again as-needed. It is also their responsibility to ensure the solution architecture documentation stays relevant to the project with any changes being updated right away. This document should be versioned so all changes can be tracked for evaluation later.
Final
After final testing, the solution architect, optionally with support from a copywriter, will turn the solution architecture documentation into the project document. A guide/manual to the project and all its parts. This may also include technical documentation extracted from the code. An evaluation document will be created that lists out the tracked changes made to the solution architecture document throughout implementation. This can be used by the solution architect and the scrum master to gain a better understanding of the changes and to make improvements to knowledge or workflows to help minimize such changes in future projects.
When the solution architect is happy with the presentation of the project they will deliver it to the stakeholders. The solution architect will be involved in any training and feedback sessions to gather change requests and plan a new phase of the project. Together with the scrum master, they will make recommendations for a maintenance team for day-to-day support of the project and the implementation team will be dissolved.
Pros and Cons
Con - Benched staff
High risk of staff being benched if they are too specialized. Certainly at the beginning of the hiring process it is important to hire versatile staff capable of working different roles to ensure they can be kept busy across different projects. For example, the copywriter role can initially be filled by the solution architect, and they may also be able to fill the business or technical roles. Another option, less optimal but easier to implement in early days, team members could be existing staff on loan from other departments for the duration of the project. Later, as the team scales, increasingly specialized staff can be hired into the project team pool.
Pro - Agile, Flexible and Scalable
The nature of the structure means team members can be added from both internal and external sources. Allowing teams to easily scale with specialist freelancers or vendors for peaks in project loads, and steadily grow by hiring into roles with a proven frequent need. All new staff will require some onboarding and training to help them acclimatize to this new way of working.
Con - hard to find the right solution architects
Many solution architects are specialized in a particular technology but for this structure it is essential that they are technology agnostic. They need to be able to identify the best technology for the project without any bias and then work with a specialist in that technology to work out the details. With the right guidance and structure in place, appropriate candidates can be trained to become the right type of solution architect.
Pro - Team Communication, Shared Responsibility and Risk
All team members must be effective in communication and bring something valuable to the table in their assigned role. They are all responsible for delivering the project goals and each member’s insights are valued equally.
Team members that only seek to follow, are not team players, are overly risk averse or have insufficient knowledge in their assigned role will be quickly identified through their lack of participation in project groups. They can be approached for a 1 on 1 discussion to find out what support they need for them to find their place in a team.
Con - BroBro-ing
While team members must certainly be able to get along it is more important that team member selection is based on their experience and knowledge being relevant to the project and not only on the fact that they are friends with another member of the group.
Pro - no fixed managers but equal team members
Helps prevent politics and managers monopolizing the best staff. Teams are created specifically for a project and are then disbanded once the project has met its goals. All team members are selected based on being most effective for that particular project’s needs.