Buy My Book, "The Manager's Path," Available March 2017!

Thursday, December 31, 2015

What is a Technology Company, Really?

I have been thinking a lot about what I want in my next job, and part of that thinking has been asking the question of what, exactly, it means to have “technology” as a core cultural value of a company.

Let’s quickly put away the idea that a “technology” company is one that produces bits, and that any company that produces bits is a technology company. By some definitions of technology that is true, but equally by some definitions of technology pretty much every modern company is a technology company, and so it dilutes into meaninglessness. Certainly, I do not think the product being produced is the interesting element for me personally. It’s likely I will always be involved in producing software of some sort, but that doesn’t say much of anything about the values of the company I produce it in. So, the production of software is certainly insufficient for a company to hold “technology” as a core cultural value, and furthermore it is silly to think that a company must ONLY produce bits to hold “technology” as a core cultural value.

As part of this thinking I started to ask myself the question, What the hell does technology mean, anyway?, and I came across the fascinating Ursula Franklin. She wrote a book called The Real World of Technology, in which she differentiates technology practices into two types: holistic and prescriptive. The holistic practice has control of the production in the hands of one person or group involved from start to finish, from determining the product, sourcing of materials, to crafting of parts, to finishing. The prescriptive process, on the other hand, is more of the assembly-line model. The steps to create the final product are broken into discrete, standardized steps that can be accomplished by different people in stages.

What does this have to do with “technology” as a company value? Well, perhaps the company value we are interested in is not in fact technology, but it is the valuing of holistic technology. As industries and practices mature, they tend to become prescriptive, whether or not it produces the “best” outcomes. Prescriptive application of technology (“technology” here being the techniques for achieving some outcome) allows for control over the process, predictability of the outcomes, and surveillance. Decisions can be made by the manager, passed down to the workers, and enforced.

However, the process of writing code is rarely completely prescriptive. Because of the difficulty in predicting what will need to change and the compounding impacts of choices made in the past, as well as the necessity for constant support and evolution that most business expect from their software these days, strong engineering teams tend to run somewhat more holistically. You may be given a discrete task (or “ticket”), but there can be a great deal of freedom in how it is implemented, depending on the size and scope, and there will almost always be need for work that cannot be easily scoped into a simple discrete task. Software has so far rebuffed efforts to fully turn it into a prescriptive style of work over long periods of time. If you are a working engineer you may think I’m joking, but while senior engineering leaders may be expected to talk a big game about “velocity” of the teams and all the measures they use to determine engineering efficiency, in reality, vanishingly few feel comfortable in the tools out there available to monitor such a vague concept, and most of us instead go by gut instinct and secondary measures like release volume and defect frequency.

So, let’s go a step further and talk about startups. In a young startup, most work is holistic. Whether you are in engineering, marketing, even some parts of finance, there are so few people that you are often given full control over your process. You are allowed to do things differently, no one is watching, there is no prescriber to tell you that you must send that marketing email on Wednesday instead of Tuesday. So early startups behave in a holistic-driven way, whether or not they hold that as a core value, because they must. However, as the startup grows, it will start to experience some need for prescriptive processes, and here then becomes the question: Can a startup that does not value fundamentally holistic technology be a “tech” startup, in the modern sense?

Most startups claim to be “tech companies”, but what do they value?

If you value “technology”, you might be saying that you value the ability to see a problem and make the changes necessary to address that problem, at a speed that would not be possible if you were having to change the behavior of humans instead of the behavior of bits. For this to happen, though, the person or group who sees the problem needs to be able to go in and do the fix. They need to be able to access the information that lets them see the problem holistically to identify that solution. This becomes relatively difficult in a prescriptive implementation, because each individual may only understand their part of the task, and only perhaps the manager or overseer understands the whole. In complex software, it is likely that no individual understands the whole, but that the group must get together and act holistically to address and solve problems. Furthermore, because of the difficulty for any one individual to see all problems, members of the group must be empowered to raise problems to the overall group, communication as peers across hierarchy and function needs to be supported and encouraged. Thus the tech company common value of “transparency.”

Or, perhaps you are saying that you value the ability for a small number of people to do work that impacts a huge number of people due to the relatively low physical footprint of software and the ease of scaling it relative to physical goods and services. The flip side is that a few people can also negatively impact huge numbers of people by making a mistake, releasing a bad feature, taking down a system. In the case of unknown and ever-changing complexity (due to ever-changing and evolving systems), you can only mitigate this by placing a high value on learning from those mistakes, and evolving your tools and practices. Because almost any member of the team has the potential to cause these problems, all members must be part of the learning process. Thus the tech company common value of “learning.”

You may just be saying that you value a type of thinking that is a combination of creative about seeing possibilities, scientific enough to quantify those possibilities, and forward-thinking enough to actually enable the ideas to thrive beyond conception. A type of thinking, furthermore, that is comfortable with change, and pushes for change as needed. This sort of thinking doesn’t generally happen in a windowless room, where people have no creative freedom and must execute the tasks handed down to them in the way they were handed down. Some companies value this but only in certain classes of people, “research” or “creative”, for example. I think that a company that places value on holistic technology will encourage this in all types of employees, and this value may be expressed as the tech company values of “data-driven”, having a “focus on impact”, and “embracing and driving change.”

And then there’s the “tech company” that isn’t

Some companies claim to be tech companies because they view technology as the company’s competitive advantage. This is the easiest, but slipperiest definition. To value it as a competitive advantage, intellectual property that forms a moat around your business, without valuing the common shared cultural values of engineers themselves, is insincere and hollow. This is the value of someone who would happily turn their engineering team into robots who produce exactly what they are asked to produce, when asked. The “value” is entirely in the difficulty of accessing the skills to turn these ideas into reality, and therefore it is only as high as the cost of acquiring those skills. This, to me, is not therefore a “technology” company. It is a company that needs technology, but does not fundamentally value it.

What does this all mean?

These are just some idle thoughts I’ve had while considering my next move. I know that I want to work somewhere that values itself not as a tech company for the intellectual property, but as a tech company for the values that I believe great engineering teams embrace. As you look around at your companies and your own values, I hope this will help you consider what it might mean for your career and future as well.

Cross-posted from Medium

Wednesday, December 2, 2015

Reorgs Happen

Yesterday I gave a talk at the NYC CTO Summit on Reorgs (slides). Here's a rough summary of the content, prior to the video release.

The general theme of this summit was "Driving Change." When I came across that theme, I immediately decided to talk about the process of reorganizations. In particular, the process of being a leader of a team involved in a large top-down reorganization. I have been in the leadership team through three of those over the past four years or so, and I have had many conversations with friends at other companies over the years who were in the middle of them, either leading them or as a person swept up in them.

My first point about reorgs is that fundamentally, in companies big and small, they happen. They are disruptive and stressful, but I personally think they are often a necessary evil, the "full GC" of organizational structure change. You can get a lot of value having smaller parts of the organization morph and change as needed, but sometimes a higher-level view of the business drives the need for larger and more top-down change.

I happened to see a tweet that led me indirectly to this blog post, and in particular, the following structure:
This is a great structure for talking about a reorganization, and in particular, your role as a leader in a reorganization.

Vision: The Vision is the "why" of what is happening. You may not be the initiator of the "why", it might be your CEO or someone else in the leadership team, but you must understand it and focus it. Usually the reasons leading to a reorg are one or more of:

  • Inefficient communication and collaboration between teams
  • Adding or removing major products or focus areas
  • Change in the size or makeup of the team

These are all well and good as a root cause, but you need to provide a lot more nuance to make this something that people buy into and want to follow. Especially when a reorg is in response to strategic change of focus. You're the leader of tech, so first make sure you understand and are on-board with the why, and then think about the way to communicate it to the rest of the engineering team in a way that makes sense. Without a clear vision, people will be confused as to why this is happening, even if what they are supposed to do when and how makes sense.

Skills: Do you have the skills to actually make the change happen? You may think that a reorg shouldn't require a lot of skills you don't already possess as a manager, but I disagree. There are many details to be ironed out in a reorg, many steps to follow, especially in a large team.

The first reorg I helped with moved our tech team from functional teams (frontend/storefront, backend) to what we called "pods", cross-functional teams with tech and product and high-level business goals. It was driven by both inefficient communication and a growing team. This was probably the easiest reorg that I led because the team was pretty small, and the lesson here is important: things that are practically free for a 20-25 person team are much more complicated when you're dealing with 60 people, let alone hundreds. The reasons were clear, we didn't need a ton of planning or incentives for people to do it, we just needed to clearly communicate what was happening why and move it through.

The most important skill for you as the leader of a large team through a reorg is communication. (In general, this is the most important skill that leaders need for pretty much everything). When reorgs go bad, one of the ways they go bad is that the reason for the change is not communicated well to the whole team, and the timing of communication is not coordinated, so some people know what's happening, others don't, and thus starts the rumor mill and the anxiety skyrockets. You are the leader. Write down exactly what the purpose is, the nuance behind it. If you need to write versions for your managers and versions for the whole team, do so. Think about your communication, and plan it as best you can.

Incentives: Why should people play along? What are they going to get out of it? You need to advocate for your team, and make sure they are going to be eager to embrace this. This is not selfish but rather sensible. If your team doesn't buy in, the reorg won't go as well, and the company will suffer for it.

Resources: Do you have available now what you need to make this happen? In the case of a reorg, that usually means time and focus. If your whole team is pushing out a major release of your mobile app, or focused on some other new launch, are you really going to distract them right now with the turmoil of a structure change? I hope not. Yes, a reorg may very well mean things need to slow down for a period of time while you figure it out and get the new teams formed, and gelled.

Of course, the other element of resources is in the new organizational structure you create. This brings us to the story of my second reorg. We had good success with the "pod" structure, but we saw that the focus for the pods was too high-level and we wanted to really get a focus on certain business strategies. We also wanted to expand the teams beyond tech/product to include other areas of the business who would be involved in the business strategies such as marketing, customer service, finance, operations. So we created what we called "strategic pillars". These were somewhat like business units, with a general manager who was responsible for the strategy of the cross-functional team (although not the people management), and members from technology, product, and the business.

Both incentives and resources were a big part of this reorg. On the initial list of candidates for general manager we did not have anyone from engineering, and I pushed to make sure that we did end up with a general manager chosen from the tech team. This was to ensure that engineering continued to be seen as an important strategic partner in the overall company, instead of an execution arm for product and business leaders. We also created a specific tech lead role for each pillar, who served as part of the pillar leadership.

As for the issue of resources, one of the mistakes I believe of the initial pillar list was creating one more pillar than we had adequate staff to support. Instead of spreading the team too thin, we simply did not staff that pillar with tech, saying that it would start out with more business analysis and research and as we came up with concrete plans we would hire into it. We ended up never getting the staffing the pillar needed to be successful, and eliminating it, which in turn was a big disappointment for the people who had been on that pillar. If you put people into leadership opportunities and then take them away, even if it is a good business decision and not an indictment of the person, they will still see it as a loss and you are very likely to lose them over it.

It's a cliché that every "Yes" you say implies a "no" to something else, but saying "no" to stretching your team too thin in a reorg is an essential part of making it successful.

Finally, the action plan. Without a clear action plan, you end up trying to start, realizing you're not ready, stopping, and starting again, sometimes many times over. You may not be the right person to make the entire action plan yourself, I know that is not my personal skill set. But you will still be involved in the planning process. If your reorg is intended to help focus people on new business strategies and goals, take your analytical mind and scrutinize those goals. Do they make sense? Are teams going to be able to work on their goals without negatively impacting other teams? If you have multiple teams with conflicting goals, you will quite possibly end up with turf wars.

This was one of the major elements of the final reorg I worked through. We had a nuanced set of goals that we wanted the teams to accomplish, and it took us several rounds of revisions to get to teams with goals that were productively aligned, independent enough to allow separate measurement without being in conflict. This process was necessary, but we suffered the downside of lacking a clear action plan, false starts, while we ironed it out. The team knew changes were coming, and they tried to tie up loose ends and finish up their work to be ready to move with the new organization. But we took longer to get the new organization together than anyone expected. With better planning earlier, we may have been able to avoid this period of uncertainty.

All of the reorgs I went through helped to move the company towards a more healthy, productive and focused structure, and I believe they were generally good for us. My final two pieces of advice for anyone managing a large team in a reorg are to remember that you don't have to do it alone, and that in the end you have to let go. Work closely with your peers to plan this, and expect that you will do some negotiating and have some outcomes that you like and some that you hate. Then, when it's out, let go. The teams will take a while to fully gel, the goals will probably shake out even more as they go through the actual process of planning on the teams. Some people will be happy with their new place, others will be unhappy and may even quit.

So, vision + skills + incentives + resources + action plan = success, right? Hopefully! However:

Reorgs are unlikely to solve all of your problems overnight. They are not a magic bullet exercise that fixes cultural issues or a lack of business strategy. If you aren't careful, your reorg will feel like rearranging deck chairs on the Titanic, a pointless waste of time for everyone involved. So don't be afraid to do them as necessary, but be realistic. This is a major disruption that impacts everyone, don't just do it for fun.