Writing Engineering Strategy
Talent and skills don’t matter if we don’t have the maturity — courage, and humility — to welcome the conditions for continuous growth. — Aaron Dignan
To write an engineering strategy, write five design documents, and pull the similarities out. Use the Design document as the backbone of the strategy. Be opinionated. Good strategies guide tradeoffs and explain the rationale behind that guidance. Write a strategy if you realize you’ve rehashed the same discussion three or four times. Bad strategies state a policy without explanation, which decouples them from the context they were made. Specific statements create alignment; generic ideas create the illusion of alignment. Good strategies could be more flexible. Companies, organizations, and technology all change enough that thinking too far into the future is fraught.
Compelling visions ground themselves in serving your users and your business. Visions should be ambitious, but they shouldn’t be audacious. Visions get more useful as they get more specific. Generic statements are easy to agree with but only help reconcile conflicting strategies.
Refine your engineering strategy from tech spec to plan to vision. For any engineering, the role is always a good practice to suggest and try to apply one or more processes. The difference in learning is significant. Write an engineering strategy and five design documents, and pull the similarities out. Companies either learn to explore or fade away.
Technology cannot speak for itself and requires effective advocates on its behalf. Impact works when individuals help set a technical vision for an area and get people moving toward that vision. Compelling ideas ground themselves in serving your users and your business. Visions should be ambitious, but they shouldn’t be audacious. Visions get more useful as they get more specific.
Write and distribute more long-lived documents, like architecture docs or technical specifications. Lead (and, to a lesser extent, take part in) company forums like architecture reviews, the company all hands, and learning circles. Internal visibility is not zero-sum but constrained by the attention of the folks you want to see your work. Share weekly notes of your work with your team and stakeholders so others can access your messages if interested. Learning and developing yourself is permanent; focus on the latter once you’ve done the smallest to clear the former’s cliff. More complex projects get derailed by personal conflict than by technical complexity. Partnering with your manager is better than disappointing them when you need to meet your expectations.
The most exact sequence is always to give the summarizing idea before you give the individual ideas being summarized. If you’re deliberate, you can influence your organization’s leaders over time. Still, you’ll only get that time if you learn to remain in tight alignment at each step. Miscommunication creates latency rather than errors. Writing forces you to think about your beliefs and data. Write everything down. Developers are translators. One scarce thing is developers who know the business side of things. Our job is to translate user requirements into functionalities. Getting information from a key stakeholder can be tricky since we all understand the system. Hiding behind complex architectures and technical jargon is easy. It gives developers a sense of control and knowledge.
A person who knows how to code is influential. A person who knows how to code and how business works is unstoppable. There are many ways to engage in business conversations and learn about your company’s domain. Learn the field of business through endless meetings with stakeholders. Elaborate on a list of the most common terms used in your industry. Start a conversation with your colleagues to understand their areas. “What are the characteristics of the sales funnel? What is marketing niches being targeted? What are the most common customer support inquiries? How is your product different from those of competitors?” Rather than relying on any individual, a more significant impact can be made on a company’s long-term success. Investing in its engineers’ development through Mentorship and guidance. The increased administrative authority provides new tools for solving problems. Retaining an executive officer in a well-managed organization requires much nuance and restraint.
The duties of an engineer vary according to the team’s needs and the Engineer’s strengths. I am most effective when I can provide direction and guidance in setting a technical vision for an area. When you reach a higher position in an organization, you must focus on the needs of the business over your own needs. Technology cannot promote itself and needs dedicated advocates advocating on its behalf.
Determining what work is in any role depends on the level of communication and commitment of the individual. Yet, engineers often follow a similar work pattern across organizations. If you need to track your projects as an engineer, it’s easy to catch yourself doing little to no high-impact work. In senior roles, you’re more likely to self-determine what you pay attention to with minimal or no management guidance.
Understanding how things ought to work is robust. Yet, you need to blend your vision with the visions of leadership and peers. Focus on what matters to make the most of your working hours, particularly as you get further along in your career and life’s commitments expand. Stay aligned with authority to remain an effective leader over time. As a senior leader, you must maintain a hold on your ego to avoid investing in meaningless work on a grand scale. Create space for others so that your team grows stronger than your contribution. Build a network of peers to vet difficult decisions and give honest feedback when your role’s authority starts to temper feedback. If something dire happens at your company, that’s where to engage.
