Posts Tagged ‘collaboration’
We are trying to change a culture of compartmentalized, start-from-scratch style development here. I’m curious if there are any good examples of Enterprise “Open Source” that we can learn from.
—Question from reader with a strong history in engineering management
When starting a new product line or dealing with multiple existing products, there’s always a question about how to share code. Even the most ardent open source developers know the challenges of sharing code—it is easy to pick up a library of “done” code, not so hard to share something that you can snapshot, but remarkably difficult to share code that is also moving at a high velocity like your work.
Developers love to talk about sharing code probably much more than they love to share code in practice. Yet, sharing code happens all the time—everyone uses an OS, web server, programming languages, and more that are all shared code. Where it gets tricky is when the shared code is an integral part of the product you’re developing. That’s when shared code goes from “fastest way to get moving” to “a potential (difficult) constraint” or to “likely a critical path”. Ironically, this is usually more true inside of a single company where one team needs to “depend” on another team for shared code than it is on developers sharing code from outside the company.
Organizationally, sharing code takes on varying degrees of difficulty depending on the “org distance” between developers. For example, two developers working for the same manager don’t even think about “sharing code” as much as they think about “working together”. At the other end of the spectrum, developers on different products with different code bases (perhaps started at different times with early thoughts that the products were unrelated or maybe one code base was acquired) think naturally about shipping their code base and working on their product first and foremost.
This latter case is often viewed as an organizational silo—a team of engineering, testing, product, operations, design, and perhaps even separate marketing or P&L responsibility. This might be the preferred org design (focus on business agility) or it might be because of intrinsic org structures (like geography, history, leadership approach). The larger these types of organizations the more the “needs of the org” tend to trump the “needs of the code”.
Let’s assume everyone is well-meaning and would share code, but it just isn’t happening organically. What are 5 things the team overall can do?
Ship together. The most straight-forward attribute two teams can modify in order to effectively share code is to have a release/ship schedule that is aligned. Sharing code is the most difficult when one team is locked down and the other team is just getting started. Things get progressively easier the closer to aligned each team becomes. Even on very short cycles of 30-60 days, the difference in mindset about what code can change and how can quickly grow to be a share-stopper. Even when creating a new product alongside an existing product, picking a scheduling milestone that is aligned can be remarkably helpful in encouraging sharing rather than a “new product silo” which only digs a future hole that will need to be filled.
Organize together to engineer together. If you’re looking at trying to share code across engineering organizations that have an org distance that involves general management, revenue or P&L, or different products, then there’s an opportunity to use organization approaches to share code. When one engineering manager can look at a shared code challenge across all of his/her responsibilities there more of a chance that an engineering leader will see this as an opportunity rather than a tax/burden. The dialog about efficacy or reality of sharing code does not span managers or importantly disciplines, and the resulting accountability rests within straight-forward engineering functions. This approach has limits (the graph theory of org size as well as the challenges of organizing substantially different products together).
Allocate resources for sharing. A large organization that has enough resources to duplicate code turns out to be the biggest barrier to sharing code. If there’s a desire to share code, especially if this means re-architecting something that works (to replace it with some shared code, presumably with a mutual benefit) then the larger team has a built-in mechanism to avoid the shared code tax. As painful as it sounds, the most straight-forward approach to addressing this challenge is to allocate resources such that a team doesn’t really have the option to just duplicate code. This approach often works best when combined with organizing together, since one engineering manager can simply load balance the projects more effectively. But even across silos, careful attention (and transparency) to how engineering resources are spent will often make this approach attainable.
Establish provider/consumer relationships. Often shared code can look like a “shared code library” that needs to be developed. It is quite common and can be quite effective to form a separate team, a provider, that exists entirely to provide code to other parts of the company, a consumer. The consumer team will tend to look at the provider team as an extension to their team and all can work well. On the other hand, there are almost always multiple consumers (otherwise the code isn’t really shared) and then the challenges of which team to serve and when (and where requirements might come from) all surface. Groups dedicated to being the producers of shared code can work, but they can quickly take on the characteristics of yet another silo in the company. Resource allocation and schedules are often quite challenging with a priori shared code groups.
Avoid the technical buzz-saw. Developers given a goal to share code and a desire to avoid doing so will often resort to a drawn-out analysis phase of the code and/or team. This will be thoughtful and high-integrity. But one person’s approach to being thorough can also look to another as a delay or avoidance tactic. No matter how genuine the analysis might be, the reality is that it can come across as a technical buzz-saw making all but the most idealized code sharing impossible. My own experience has been that simply avoiding this process is best—a bake-off or ongoing suitability-to-task discussion will only drive a wedge between teams. At some level sharing code is a leap of faith that a lot of folks need to take and when it works everyone is happy and if it doesn’t there’s a good chance someone is likely to say “told you so”. Most every bet one makes in engineering has skeptics. Spending some effort to hear out the skeptics is critical. A winners/losers process is almost always a negative for all involved.
The common thread about all of these is that they all seem impossible at first. As with any initiative, there’s a non-zero cost to obtaining goals that require behavior change. If sharing code is important and not happening, there’s a good chance you’re working against some of the existing constraints in the approach. Smart and empowered teams act with the best intentions to balance a seemingly endless set of inbound issues and constraints, and shared code might just be one of those things that doesn’t make the cut.
Keeping in mind that at any given time an engineering organization is probably overloaded and at capacity just getting stuff done, there’s not a lot of room to just overlay new goals.
Sharing code is like sharing any other aspect of a larger team—from best practices in tools, engineering approaches, team management—things don’t happen organically unless there’s a uniform benefit across teams. The role of management is to put in place the right constraints that benefit the overall goals without compromising other goals. This effort requires ongoing monitoring and feedback to make sure the right balance is achieved.
For those interested in some history, this is a Harvard Business School case on the very early Office (paid article) team and the challenges/questions around organizing around a set of related products (hint, this only seems relatively straight-forward in hindsight).
When starting a new product there’s always so much more you want to do than can be done. In early days this is where a ton of energy comes from in a new company—the feeling of whitespace and opportunity. Pretty soon though the need for prioritized lists and realities of resource/time constraints become all too real. Naturally the founder(s) (or your manager in a larger organization) and others push for more. And just as naturally, the engineering leader starts to feel the pressure and pushes back. All at once there is a push to do more and a pull to prioritize. What happens when “an unstoppable force meets an immovable object”, when the boss is pushing for more and the engineering leader is trying to prioritize?
I had a chance to talk to a couple of folks facing this challenge within early stage companies where a pattern emerges. The engineering leader is trying hard to build out the platform, improve quality, and focus more on details of design. The product-focused founder (or manager) is pushing to add features, change designs, and do that all sooner. There’s pushback between folks. The engineering leader was starting to worry if pushing back was good. The founder was starting to wonder if too much was being asked for. Some say this is a “natural” tension, but my feeling is tension is almost always counter-productive or at least unnecessary.
There’s no precise way to know the level of push or pushback as it isn’t something you can quantify. But it is critically important to avoid a situation that can result in a clash down the road, a loss of faith in leadership, or a let down by engineering.
As with any challenge that boils down to people, communication is the tool that is readily available to anyone. But not every communication style will work. Engineers and other analytical types fall into some common traps when trying to cope with the immense pressure of feeling accountable to get the right things done and meet shared goals:
- Setting expectations by always repeating “some of this won’t get done”. This doesn’t help because it doesn’t add anything to the dialog as it is essentially a truism of any plan.
- Debating each idea aggressively. This breaks down the collaborative nature of the relationship and can get in the way, even though analytical folks like to make sure important topics are debated.
- Acting in a passive aggressive manner and just tabling some inbound requests. This is almost always a reaction to “overflow” like too much sand poured in a funnel—the challenge is just managing all the inbound requests. This doesn’t usually work because most ideas keep coming back.
What you can do is get ahead of the situation and be honest. A suggested approach is all about defining the characteristics of the role you each have and the potential points of “failure” in the relationship.
As the engineering leader, sit down with the founder (or your manager) and kick off a discussion that goes something like this as said from the perspective of the accountable engineering leader:
- We both want the best product we can build, as fast as we can.
- I share your enthusiasm for the creativity and contributions from you and everyone else.
- My role is to provide an engineering cadence that delivers as much as we can, as soon as we can, with the level of quality and polish we can all be proud of.
- We’ll work from a transparent plan and a process that decides what to get done.
- As part of doing that, I’m going to sometimes feel like I end up saying “no” pretty often.
- And even with that, you’re going to push to change or add more. And almost always we’ll agree that absent constraints those are good pushes. But I’m not working without constraints.
- But what I worry about is that one day when things are not going perfectly (with the builds or sales), you’ll start to worry that I’m an obstacle to getting more done sooner.
- So right then and there, I’d like to come back to this conversation and make sure to walk through where we are and what we’re doing to recalibrate. I don’t want you to feel like I’m being too conservative or that our work to decide what to do in what order isn’t in sync with you.
That’s the basic idea. To get ahead of what is almost certainly to be a conversation down the road and to set up a framework to talk about the challenge that all engineering efforts have—getting enough done, soon enough.
Why is this so critical? Because if you’re not talking to each other, there’s a risk you’re talking about each other.
We all know that in a healthy organization bad news travels fast. Unfortunately, when the pressure is on or there’s a shared feeling of missing expectations often the first thing to go is the very communication that can help. When communication begins to break down there’s a risk trust will suffer.
When trust is reduced and unhealthy cycle potentially starts. The engineering leader starts to feel a bit like an obstacle and might start over-committing or just reduce the voice of pragmatic concerns. The manager or founder might start to feel like the engineering leader is slowing progress and might start to work around him/her to influence the work list.
Regardless of how the efficacy of the relationship begins to weaken, there’s always room for adjustment and learning between the two of you. It just needs to start from a common understanding and a baseline to talk and communicate.
This is such a common challenge, that it is worth an ounce of prevention and an occasional booster conversation.
In the course of figuring out what to do on a project (plan, code, collaborate, marketing, …) inevitably you will get to a point where two parties (two people, two teams, two disciplines) don’t agree. Figuring out how to move forward is not only essential, but is something that can make or break a team or project.
Focusing a discussion on disagreement in the abstract is a good way to approach this, rather than using specific examples. This allows the dynamics to be discussed here without the distractions of picking sides. When it comes to disagreements, even the specifics are usually much less important than the overall context in which the disagreement is taking place. More often than not, a focus on specifics tends to hide what is really the root of a disagreement.
This post was suggested by a reader as a topic worth discussing. Suggestions are welcome and I’m always on the lookout for comments and tweets with suggestions or email me at firstname.lastname@example.org, perhaps with something going on at your organization right now that is a generally interesting topic (specifics always removed).
Organization plays a key role in the context of building consensus (more on organization in a follow up post). Is your team managed step by step through a hierarchy, deferring to the management chain? Is your team one where the most senior manager gets involved in many choices? Is your team dominated by a strong de facto leader that leads from within the team? Is your team a small group of peers that seem to usually agree on everything? Is your team subject to swoop and poop from outside, bringing disagreement to you? There are quite a few ways that disagreements can surface and/or get resolved and those are a few.
The first step in working through disagreement is to know how your team is structured to make choices, which might be different than the org chart. You want to know not just how you want to decide things, but how do others in all 360 degrees expect to resolve things.
The 360 degree view has been something I have often worked through (and certainly not perfectly). In a team with a plan and a strong organization, it is the organization working with a decision framework, the plan, that decides. Those new to the team or even those on other teams often see a team operating this way and assume a hierarchical or top down model—otherwise how could things appear to work and stay on track with a large project.
In practice what that means is that there is a mismatch in how to handle disagreement. Some assume that you have to go to the top and “get things changed”, while folks at the top are saying “did you talk to the people doing the work.” This type of cultural mismatch is the first thing to overcome. On a team of empowered creative folks, they have gone to great lengths to say what they will be doing and how they will decide what is yet to be discovered. That’s always been enough for me.
Roles and responsibilities in an organization, not hierarchy, are also important. Are disagreements between people within the same discipline or across disciplines? Often agreements can be settled by recognition of where the responsibility rests. For example, in projects with user interface many people can have opinions about the UI but the team should be operating with acknowledgement that the accountability rests with the discipline (design, program management) that is doing the work to design the UI. Having a clear view of how specialties work in the organization is an important part of knowing how disagreements will be resolved.
Organization can cause disagreement to flourish in two main ways. First, management can structure things such that goals and/or accountability are unclear. This means things need to be integrated or reconciled “up” where there is always less information/data, thus driving meetings, debate, and campaigning for decisions. Second, members of the team can fail to defer to the empowerment and decision making structure in place (plans, disciplines, accountability). This is a case where disagreement exists when individuals on the team could take time to step back and let the organization do the work.
These organizational elements are an important part of the context around disagreements.
What is it that makes disagreement so pervasive and so difficult to work through? Are there really so many arguments to be had while building a product or service once you decide what can and should be built?
I’ve always been fascinated by the dynamic of how something turns into a big decision to be made. For me, work is progressing and sometimes things come up that are hard or unforeseen. Then all of a sudden there is a crisis and something needs to be decided and that decision has expanded to involve a lot of people.
Knowing the context is always the most important first step. The following are some examples of reasons or context behind disagreement:
Decision or an argument. A first consideration is if there is truly a decision to be made or what is really going on is an argument. What this means is to ask if someone questioning your general approach or is this a real challenge to the choices you are making. It is only to your advantage to engage with members of the team who might have a different point of view. You don’t have to accept it or escalate into a fight, but it is always good for everyone on the project to be heard.
Naysayers. Sometimes a decision gets created that is not really all that important, but is being used to drive a wedge for any variety of reasons. Often these look like “let’s take a step back and ask the following question.” So you thought you were having a discussion about a schedule estimate and the next thing you know you are in the weeds debating agile v. waterfall. You have to ask yourself if the real issue is the meta-issue, a lack of faith in everything going on, or if you really have something that is the source of a disagreement.
First of many. There are times when points of difference get raised in a “death by 1000 cuts” sort of way. In other words you might find yourself disagreeing over a specific topic but as you’re talking (constructively) it becomes clear that this is going to be the first of at least a few disagreements. Folks might use this approach to test the waters or to probe for a weakness overall. An approach here is to work to smoke out all the disagreements so you can have a discussion with the full context.
Symbolic or material. Sometimes a disagreement is really an effort to raise a more symbolic disagreement with the broader context of the project. Helping to work through and discuss how material a given disagreement is to the whole project is especially important here. In this context, a disagreement can turn into a broader view of two parties not connecting.
Accountability. Ultimately disagreement needs to factor in accountability. If the first step of a disagreement is “who gets to decide” it is likely the answer will itself become a disagreement. Almost all disagreements I have been part of scream out the person who should be deciding. If it doesn’t the question is really more about accountability—not who should make a specific choice, but who is accountable for a broader set of issues. Is that person not doing a great job incorporating lots of viewpoints and information? Did that person not enroll everyone in a broader framework?
Context is everything. In the heat of a disagreement people, especially for engineers who tend to distill things into concrete facts or algorithms, will often get very focused on the details of winning the argument. It is a good idea to understand the context of the disagreement before trying to win on the merits.
What can go wrong?
As you’re working through a disagreement, there might be a few patterns you run across that are used to resolve the disagreement—patterns that might not be the most productive.
The key thing is to keep the dialog focused on the context of a choice. In a sense, what I think everyone knows is that any disagreement free of context can have a different outcome than if considered in the context. A classic is “add this feature.” Absent the context of schedule, resources, and most importantly the holistic view of a plan/product, almost any feature sounds like a good one to add or any change seems reasonable. The flip side is that just about everyone sounds like an idiot arguing against security, performance, quality absent the context that an engineer might have. No one sounds smart arguing against a revenue opportunity, until you consider the cost, alternatives, and so on.
There are patterns that are bad ways to resolve disagreement because the technique removes the context:
Single choice. Sometimes when there is a disagreement, something that seemed small starts to take on a life of its own. You come to a meeting and you’re all of a sudden having a debate over the color of tooltips in a toolbar (true story) when that is not really the disagreement as all. What has happened is a disagreement over a broad set of issues has morphed into what appears to be a single choice. The context was lost and a complex, multi-dimensional problem space has been replaced by one, seemingly, trivial option.
Escalation. Sometimes disagreements get created as a way to get in front of the boss or as a way to encourage the boss to get in front of the other party. This type of disagreement is never good and my first reaction is to pull back and “de-escalate” like cops do on reality shows. Something I have always tried to practice is the notion that to escalate is to fail. But the real challenge with escalating a disagreement is that the context and knowledge about a situation is reduced as you move up the management chain, so escalation is really a way of saying “decide with less information.” There are subtleties and nuance to this (for example if you haven’t done your work to incorporate the context from outside your specialty in creating a plan). New information can change things and the question is whether you are being too heads down to incorporate new information. The key is that once you escalate you lose the context of the choice. Similarly, to pull a decision up (the organization) creates the same dynamic of deciding with less information than might be available.
Decision maker. One way to remove the context from a disagreement is to introduce a debate over who gets to decide, as mentioned above. I’ve been part of all sorts of “tools” that are supposed to help you decide—tables of who reviews choices, approves things, or “responsibility assignment matrices.” As well-intentioned as these are they don’t really scale and they encourage all choices to get broken out into elaborate decision-making processes. At some point you can rationally ask how to even decide what decisions go through a process like this or is this an attempt to circumvent accountability or an attempt to game the system.
Accountability shift. Accountability gets to the heart of most disagreements. Those disagreeing feel on the hook, accountable, for some outcome and the choice being discussed impacts the potential for achieving the assigned goal. By shifting the dialog from the disagreement to accountability, things get emotional very quickly. The discussion turns into talk of “failure” which is a lot to place on the shoulder of a single choice in a complex product.
Tools and approaches
In practice the tools to reconcile disagreements are rather personal—they rely on the skills, tone, and temperament of the individuals. Most everyone can lose their temper or go silent (essentially the same thing). Most everyone has sent a late night mail they regret (subject line, “thoughts”). Most everyone has behaved the way they criticized someone for behaving. I’m there with you and don’t have magic answers to resolving disagreements. Here are a few tools I have used:
Expertise. Where is the most expertise? As a general rule, too often decisions are made in meetings where people are presenting cases and someone is in the middle trying to referee or decide. At that moment, a decision is being made by a committee or by a group, yet the people that have the expertise might not even be in the room. As a general practice, pushing decisions to those that know the most yields better decisions. Many times teams convince themselves that there are implications that go beyond the expertise (“yes this might be a security problem but the business has different issues”). The best thing then is to figure out how this type of context is not making it to the domain experts—what was missing from the day to day flow of information that got a team in a situation to begin with?
Plan. Most disagreements are essentially disagreements with a broader view—at the highest level or at the level of what a feature or marketing message should accomplish at the core. In other words, while the discussion might be about a specific, it is a disagreement about a broader theme. I return back to the plan (the one you got buy-in about because you talked about it broadly). I try to understand what has changed or what have we learned since the plan. Plans are dynamic of course. But one needs to be careful about changing direction without a real change in the business or product landscape. If you do change plans, you need to think hard about the relationship of one change to the big picture.
Culture. The best tool for resolving disagreements is one you have to put in place upstream, which is a culture that allows and respects the decisions being made by the right people. Developers might not like the advertising, but marketing people decide that. Marketing might not like the wording of a license, but that’s a decision for lawyers to make. But because a team should be operating with a shared view of customers, the decisions should be ones made outside of silos of expertise or narrow views of success. There’s definitely magic in there and in a big project achieving this uniformly is extremely difficult, at best. The tool everyone should ask for in a culture is a management chain that supports the culture. It isn’t about being “backed” in a decision but about being consistent in the notion of delegation and accountability.
Accountability. Related to culture is the notion of accountability. Rather than saying “test is accountable for quality” the tool is really for management to reinforce that everyone is ultimately responsible for the overall result. If something is successful you can bet that everyone on the team will feel they contributed to the success. There’s nothing stopping the team from acting that way while the product is under development.
When to say when. Finally, the best tool any individual can have in the course of a disagreement is knowing when to say when. Projects are marathons (no matter how long a particular coding sprint might be). If you choose to turn every decision into the most important and biggest one, you’ll run out of reserves long before the finish line.
One final consideration is if you agree to disagree then you have to mean it. It means you can’t remind folks at every opportunity that you saw things differently. It also means you’re tabling the disagreement for good and that you’re not inadvertently establishing a dreaded accountability dodge or told you so for later on.
There are innumerable decisions in any project—each person, then each team, then teams, and more each make choices dozens of times a day. Every line of code, every word in a spec, every automated test, every part of a plan, every data sheet, PR script, and more are decisions.
People tend to forget this in the heat of the moment. Time heals, and forgets, most every small decision in a project. In fact, I would bet that any disagreement you are dealing with at this moment will be a distant memory and chances of it determining success and failure of your project are small when viewed in the context of all the work, and decisions, yet to be done. Om.
Reminder – please see the recently added disclosure page.