Infinite possibility is exciting for a software team, however, using only reactive engineering tactics is not sustainable. Debt mounts, the team slows, and change becomes hard. Instead of working with product and design colleagues (contributing to strategy even), engineering is always playing catch up. So then, how can your team chart a course to a truly faster, collaborative and flexible future? Create a technology north star and a map to get there!
This topic, a popular one in Atlassian, was great to get back to while applying it in a startup context. I’ve sought to make it more broadly applicable still, so like a lot of my writing, I trust you’ll find takeaways useful for your context.
There are two parts to this topic:
Creating a technology north star. (this part)
Mapping a technology north star.
(side note: I’ll get back to the velocity equation!!! This became a hot topic for me at Qwilr so I’ve willingly diverged…)
Describe a better future
A north star is a description of a better future. To be balanced and focussed, its creation requires different perspectives and collaboration.
A good north star is also aware of the current state, relevant to the problem, and contextual to the team. Setting this context is a great shared starting point before exploring distinct perspectives to sharpen the definition.
Look inside
Looking within the development team can highlight drivers for change and better describe the desired destination.
Engineering excellence 🎯
What dev speed, quality, process other engineering challenges is your team facing? Where do you need to lean in to improve?
Some ideas:
Fast, independent delivery
Improve efficiency and throughput
Reduce complexity
Flexibility to change
Build to run and maintain
One platform for multiple consumers
Rent-over-build
Quality through fast feedback
Operational excellence 💡
What operational metrics need attention? What pressures for and against these operational metrics are anticipated in the coming quarter/year?
Some ideas:
Performance & Scale
Supportability (contact index)
Bugs & Incidents
Security & Privacy
Availability & Reliability
Team awesomeness 🎽
Conway's law is real - architecture and the team are related and tend to resemble each other. What factors ahead are forces for and against your team and their relationship with the north star? Are there different subgroups in your team that have contrasting concerns? How are they balanced?
Some ideas:
Focused purpose and goals.
A clear path of delivery.
Code ownership and maintenance.
Expectations of the team and dependencies.
Expertise in features, code and technology.
Flexibility to trade-off priorities.
Effective ways of working.
Look around
We create customer value as engineers. As a "north constellation", business and technology north stars should support each other, creating a meaningful picture when "joining the dots".
Product and experience outcomes 💎
It's harder to define a strategy unlocking product, experience and engineering outcomes, making the feature impossible today, possible tomorrow, but that's a key reason for having a technology strategy! Work with product management/design on product outcomes/experiences needing transformation. Who you work with depends on the organisational and project context. Is there clarity on the vision in those areas or does the north star need to bring flexibility? A useful question to ask these colleagues is “If the effort were not a blocker, what would be the most amazing thing you’d want us to build?”
Organisational dependencies 🤝
What are the dependencies between your team and others that would improve through engineering changes? For example, should you be better consuming or providing services from/to other teams? How does this north star support or detract from other engineering initiatives? Just as your north star should align with business objectives, so it should also align with other technology north stars and broader technology strategy.
Platform and APIs 🧱
External developers can be neglected if your product is primarily a user experience. What platforms (infrastructure, reuse, automation, extensibility or more) are relevant to your product? What aspects of the "look inside" section apply to these external developers? How can the effort be shared across capabilities for external developers, internal developers and regular customers?
Look outside
Even with a technology focus, it is beneficial to get inspiration by looking outside the organisation.
What trends, opportunities, and threats do you see in the technology industry that should impact your north star? What do you see as your team's advantage or disadvantage compared to a fast-moving, agile startup that's decided to disrupt your product? How can you out-execute if you are the disruptor? What about your incumbent competitors?
If you have been maintaining a technology radar, that would be a significant input into this exercise.
Build a rubric
A shared understanding of internal and external drivers gives us a rubric, the quality criteria used to evaluate different north stars.
Aim to simplify the rubric
Inspiration from earlier sections and brainstorming may have resulted in a large number of drivers listed. State a shared challenge to whittle the drivers down to the top 3-5.
The first filter is relevance. Don't keep drivers that are clearly unrelated/low-value for your team; also consider renaming them to improve clarity and relevance.
Exercise: Paper, rock, relevance!
Break up into groups, with each group doing a "paper rock scissors" on which of the categories or drivers (looking inside, around or outside) are critical for the time horizon of the north star.
One way of scoring is:
Thumbs down - This is less relevant to us.
Thumbs sideways - Important to maintain but not invest in.
Thumbs up - Important to invest in.
Double thumbs up - F$#k yes! We have to do this!
Use planning poker techniques to discuss different responses and align/average.
Drag to reposition.
Represent different views with north star themes
If there are differences in views on the rubric that are hard to reconcile, consider defining one or more "north star themes" representing these different perspectives. This tactic can keep the team moving forward, as seeking to force absolute alignment here typically will only see differing views from resurfacing in later steps.
Identify north star candidates
A technology north star is a future state of architecture, team and execution ability. If you stand in the future, it's what you observe.
If you have alignment on drivers, possibly with a few alternate themes, you are ready to identify candidates for a north star. For example, one candidate might emphasise engineering drivers like dev speed. Another might address flexibility in light of a significant external threat. Or, the product strategy is ambitious; hence the technology north star needs to lean into making it feasible.
If you have divergent themes, embrace starting with those, but encourage groups in subsequent rounds to abandon bad ideas and adopt good ones from others to get balance and convergence.
If the groups are convergent, consider challenging if you think the team is not exploring enough alternatives. For example, challenge one group to emphasise using off-the-shelf technology and another to emphasise proprietary technology development. Inviting a connected person or team from elsewhere in the organisation can also bring a different perspective.
Exercise: The future interview
A fun exercise for defining a north star candidate is the "future interview". Imagine that it's 3 years down the track and that you're being interviewed by TechSponge (the leading tech news service) about your success in transforming your engineering team and product. What do you answer for these questions:
What were the two biggest challenges you needed to overcome in your engineering team?
What was the biggest achievement you accomplished during that time?
If we interviewed someone on your team what would they say had changed the most?
If you're the facilitator have a bit of fun at being the interviewer.
That's it for part 1!
Congratulations, you are on your way to defining a technology north star! Next up will be creating a map to get us there in part 2.