I’ve spent most of my career — now well over two decades of it — building things on the web. I’ve worked as a software developer, I’ve founded a couple of my own companies, and I’ve often found myself leading teams of engineers. Right now I’m the director for both engineering and IT (although there are teams of people who write code who aren’t under my wing — newsrooms are complicated).
Over time, a lot of my work seems to have become less about “what shall we build?” or “how shall we build it?”. Those questions are always vitally important, but there are prerequisites that sometimes need to take center stage: things like “what are we here to do?”, “how should we work together?”, and “how do we think about what matters?”
I’ve been sharpening my thinking about the necessary conditions to do good work, and how to achieve them. Here’s a window into how I’m thinking about these ideas across three dimensions: Organizational Context, Team Leadership, and Technology Trends.
Organizational Context
There’s an unattributed but often-quoted management strategy cliché that says: culture eats strategy for breakfast. I’m a believer. Culture contains the fundamental building blocks of how an organization acts as a community: its values, beliefs, attitudes, norms, processes, and rules. Without a strong one, you cannot succeed — regardless of what your strategy looks like. Conversely, a great strategy, by definition, is one that incorporates building a great, intentional culture. Without one, your team is more likely to burn out and leave, you’re much less likely to build something high-quality, and you’re unlikely to foster new ideas.
Software engineering, at least in the places I’ve practiced it, is all about innovation. The focus is rarely on maintaining the present, although some degree of maintenance is always necessary. Instead, it’s about building the future: figuring out what we’ll need our platform to look like in two to five years and finding ways to get there. It’s a creative pursuit as much as it is about rigor and craft, and it’s about values and taste as much as it is about business necessity.
This dynamic is well-served by some organizational cultures and actively undermined by others. The trick is figuring out which you’re in, and finding ways to either embrace the former or build a buffer zone for the latter.
One popular way of looking at organizational culture is the Competing Values Framework, which defines four distinct overall culture types — all four of which are usually present to different degrees inside an organization.
- Adhocracy: an organic, unbureaucratic way of organizing work that challenges the status quo, formal titles, and hierarchy in favor of a focus on risk-taking and innovating at speed.
- Clan: a family-like culture that, again, is relatively unbureaucratic, without much structure, where rules tend to manifest as social norms rather than edicts or rigid process.
- Hierarchy: where an emphasis is placed on top-down control from upper management in order to create predictability and lower risk. Roles are clearly defined, rules are codified, and even internal communication tends to be stratified.
- Market: a culture optimized around competition, both with competitors and internally. Measurable results are central, but the workplace can easily become toxic because everyone is trying to better themselves vs their peers.
Like many frameworks, the reality is not actually as cut and dry as this. Instead, I think these categories are best thought of as facets of an organizational culture. In some organizations, hierarchy and market focus may have a heavier emphasis; in others, innovation and collaboration.
I vastly prefer working within organizations that look like the first two environments — adhocracies and clans — and I’d hazard to say that almost every single engineer, designer, and product manager I’ve ever worked with feels the same way. Hierarchical systems are inherently creatively stifling: innovation can’t take place in an environment with predominantly top-down control. The same goes for hyper-competitive environments: while the competition might be motivating for some in the short term, it’s really hard to collaborate effectively and build on each others’ ideas if everyone is trying to get ahead of each other.
Hierarchies in particular definitionally strip your authority in favor of top-down direction, forcing you to negotiate through layers of politics to make any kind of change. Most good engineers are collaborators, not cogs, with ideas, expertise, and creativity that should be embraced. But hierarchy demands cog-like behavior, and creates institutional fiefdoms that tend towards bureaucracy, inhibiting any really new work from being done if it hasn’t been rubber-stamped. These aren’t great places for a creative person to work.
As Robin Rendle put it recently:
This is the most obvious thing to say in the world, but: the hard work should never be the bureaucracy, it should be designing things and solving technical problems. If the hard work ain’t the hard work, ya gotta bounce. Don’t kill yourself trying to tell people that.
That isn’t to say that every team in an organization should work the same way or strive for the same culture. It might be that a legal, compliance, or safety team needs to work in a more rigid way as a system of control, or that a sales team needs to be intensely market-oriented. Or those things might not be true at all! My point is that it’s a mistake for engineers to assume that because they work best in a particular kind of environment, everyone should work that way. Every organization is comprised of a mix of culture types, and every team needs to work in a way that allows them to do their best work.
This may seem obvious, but we often talk about a single team’s working style setting the cultural norms for a whole organization. For example, it’s common for an organization to be described as engineering-led or sales-led. To be clear, this is a false choice: there should simply be people-led organizations that are inclusive of different interdisciplinary needs and styles of working.
For that to be a reality, top-level leadership in particular needs to acknowledge that not every team works the same way. For my purposes, this means acknowledging that engineering needs a particular kind of culture in order to thrive (and is important enough to have its own culture and be deserving of autonomy).
A prerequisite to this is understanding the potential for a technology team (or any team) in the first place. That’s less likely to happen in organizations where it’s treated as back-office, paint-by-numbers work. If an organization can’t see the importance of a team’s work, and if it inherently does not respect the effort and expertise inherent in those roles, it’s going to be very difficult for them to do good work.
My bias is to lean heavily on storytelling and listening as tools for fostering understanding: finding ways to explain why the work of product and engineering is important in the context of the whole organization, and how that expertise can be leveraged in order to benefit everybody. It’s okay to not understand what an engineering team has the potential to do from the outset, but if organizational leaders continue to not understand, that’s on me. The way to get there is through being transparent about what we’re doing, how we’re thinking, and which challenges we expect to encounter.
It really matters. Mutual understanding begets mutual respect.
There needs to be an explicit understanding between teams, mutual respect between parties that encompasses their expertise and different ways of working, and loose protocols for how everyone is going to communicate with each other that is compatible with their different styles of working.
I shouldn’t presume to tell a team from another discipline what they need to do their job, just as they shouldn’t presume to tell me. I should treat another team as the expert in its discipline, and they should treat my team as the expert in mine.
Throughout all this and despite our differences, we’re all in the same boat. We need to all be pulling in the same direction, motivated around a single, motivating mission (why we’re all here), vision (what is the world we’re here to try to create), and strategy (what are we going to try and do next to make it a reality).
The role of upper management is to set the direction, foster a culture that supports everyone, and help to build those protocols (all while not running out of money). One role of team leaders is to navigate those protocols and act as a buffer where there is friction.
Team Leadership
Vulnerable, open leaders make it safe for everyone to take risks and show up to work as they are.
So far I’ve written a lot about how engineering teams need organizational support that starts with a compatible culture that is founded on respect. But even in an environment that is un-hierarchical, transparent, informal, respectful, and open, with clear organizational goals and a defining mission, there’s more work to be done in order to create an environment where engineers can do their best work.
As I wrote last year:
The truth is that while some of the tools of the trade are drawn from math and discrete logic, software is fundamentally a people business, and the only way to succeed is to build teams based on great, collaborative communication, human empathy, true support, and mutual respect.
Leaders need to be stewards of those values. I believe — strongly — that this is best achieved through servant leadership:
[Servant leadership] aims to foster an inclusive environment that enables everyone in the organization to thrive as their authentic self. Whereas traditional leadership focuses on the success of the company or organization, servant leadership puts employees first to grow the organization through their commitment and engagement. When implemented correctly, servant leadership can help foster trust, accountability, growth, and inclusion in the workplace.
Each of these are important; I would also add safety. A blame-free environment where everyone can speak openly, be themselves, make mistakes, and not feel like they have to put on a mask to work is one where people can take risks and therefore innovate more effectively.
When you’re facilitating a brainstorming exercise, you might intentionally throw in a few out-there suggestions to make participants feel comfortable to take risks with their own contributions. Similarly, one of the roles of a leader is to push the envelope, and maybe risk looking a bit silly, in order to allow other people to feel more comfortable taking risks with their work — and when they do, to cheerlead them, support them, and help them feel comfortable even if their ideas don’t work out.
In a hierarchical team, the leader might ask if team members are adhering to their standards. In a supportive team, the leader might primarily ask how they are doing at supporting their team. It’s not that you don’t ever ask if someone isn’t performing; it’s more to do with the center of gravity of assessment. Supportive teams put the employees first.
Fostering that sort of team culture heavily depends on how a manager shows up day to day. A manager who isn’t vulnerable, doesn’t reveal much of themselves, and requires homogeneity is — probably unintentionally — fostering a hierarchical culture where masking is the norm rather than a supportive one where people are free to to be themselves.
The same sorts of fractal dynamics that affect inter-team collaboration apply to inter-personal collaboration, too. Everyone is different and has different working and communication styles, and homogeneity should never be the goal.
You can tell a lot by a team’s approach to feedback. If it is given in one direction — from managers down — then you likely have a hierarchical culture where team members may be less able to speak up and share their ideas. (The same is true if feedback is sometimes given to managers but rarely acted on.) I’ve observed that the most successful teams have clear, open, 360-degree feedback loops, where everyone’s feedback is directly sought out and incorporated — from team members to managers, between team members, and from manager to manager.
Another observable difference in team cultures can be seen through the kinds of norms that are enforced. To the extent that there are hard and fast rules on a team, they should be grounded in a purpose that supports forward motion, rather than to provide comfort to leadership or simply to enforce sameness.
As illustration, here are two contrasting examples of norms I’ve often seen enforced on teams:
- Source code is written to adhere to common style guidelines, and is peer reviewed.
- Cameras should be turned on during video calls.
Common coding style rules are a social contract that lower the cognitive load of working with code that someone else on the team has written, removing important roadblocks to everyone’s work; peer review is a really great channel for feedback, learning, and preventing bugs. Meanwhile, enforcing that cameras should always be on during video calls only serves to make some people less comfortable on the call.
Ultimately, success here is measured in what you ship, how happy your team is, whether they recommend working at your organization to their friends, and how long people stick around for.
Technology Trends
It’s important for an engineering team to not just have a competence in working with technology but to have strong opinions about it, its implications, and how it intersects with the lives of the people it touches. They should strive to be experts in those issues, learning as much as they can from relevant publications, scholars, and practitioners.
It would be ludicrous to examine the use of AI but not study its ethical issues. Not only is there a moral hazard in not understanding the subject holistically, but by leaving out topics like bias, intellectual property violations, and hallucinations as you investigate bringing AI into your work, you actually create liability for your organization. It’s both an ethical duty and good due diligence.
Similarly, imagine studying blockchain a few years ago but not covering its environmental impact or its potential for use in money laundering. Leadership might have been excited by the potential for financial growth, but by not examining the human impacts of the technology, you would have missed substantial risks that might have created real business headwinds later on.
Or imagine relying on developing code as a core function of your organization and not staying on top of new techniques, approaches, exploits, and technologies to build with. Your team would effectively be stuck in time without any real way to progress and stay relevant, creating a risk that your product would suffer over time.
Or, come to that, imagine working in a fast-moving field like technology and not forming a strong, informed opinion about how it will change that is rooted in learning, experimentation, and active collaboration with experts and other organizations.
This is another area where an open, collaborative, inclusive culture can be helpful. Giving space to team members who want to share their knowledge and ideas about a subject, and entrusting them to cover it from their perspective, helps allow for topics to be covered through the lens of a variety of diverse lived experiences. But by practicing and championing the idea of inclusion as a core team value, you encourage team members to actively go and speak to diverse experts and gather a variety of viewpoints. The gene pool of ideas is widened as you investigate a subject and your own ideas and resulting products and strategies will be stronger as a result.
In a hierarchical culture where strategy is set from the top down, this kind of broad, inclusive learning might not be as effective, or it might not be present at all. Servant leadership helps ensure that everyone has the space to learn and grow with respect to topics they may not have mastered yet, or that their perspectives are championed. You simply have access to fewer ideas from fewer perspectives, and you’re wildly limited as a result.
Those same open feedback channels that create well-functioning, communicative teams can also serve as a way for team members to learn from each other. The principles of openness, inclusion, respect, openness to risk, and collaboration can serve as guiding lights as teams navigate new technologies and help their respective organizations get to grips with these topics. Leaders have a role in fostering learning and knowledge-sharing on a team, and ensuring that it is a first-class activity alongside writing and architecting code.
Overall
A lot of the things that are important to get right with engineering aren’t really about engineering at all. The best teams have a robust, intentional culture that champions openness, inclusivity, and continuous learning — which requires a lot of relationship-building both internally and with the organization in which it sits. These teams can make progress on meaningful work, and make their members valued, heard, and empowered to contribute.
At a team leadership level, servant leadership is a vital part of fostering a culture of innovation and adaptability. By prioritizing the well-being and development of the people on their teams, leaders are making an investment that leads to higher performance, more nuanced strategy, more resilience, and lower churn.
At an organizational leadership level, a clear strategic direction and a focus on inclusivity help to provide the leeway to get this work done. I don’t know if you can succeed without those things; I certainly know that you can’t create a satisfying place for engineers and other creative people to work.
The most interesting and successful organizations have an externally-focused human mission and an internal focus on treating their humans well. That’s the only way to build technology well: to empower the people who are doing it, with a focus on empathy and inclusion, and a mission that galvanizes its community to work together. And, perhaps most importantly to me, that’s the only way to build a team that I want to work on.
That’s how I’ve been thinking about it. I’d love to read your reflections and to learn from you.
Share this post
