Featured in Architecture & Design

Monal Daxini presents a blueprint for streaming data architectures and a review of desirable features of a streaming engine. He also talks about streaming application patterns and anti-patterns, and use cases and concrete examples using Apache Flink.

Featured in AI, ML & Data Engineering

Joy Gao talks about how database streaming is essential to WePay's infrastructure and the many functions that database streaming serves. She provides information on how the database streaming infrastructure was created & managed so that others can leverage their work to develop their own database streaming solutions. She goes over challenges faced with streaming peer-to-peer distributed databases.

Designing Menlo - a Conversation with James Goebel

I recently spent a week at Menlo Innovations exploring what makes the organization so successful and how they have created a culture of joy in work. My thoughts and discoveries were written about in three articles exploring their culture, project management approach and High-Tech Anthropology®.

During the week I spoke to James Goebel, COO and cofounder to get his thoughts and ideas about why and how they designed the organization and its culture in the way they did.

InfoQ: James, thanks for taking the time to talk to me today. You are nominally the COO here, but what does that really mean in the Menlo context?

James: Often, people refer to Menlo as the bossless office. I’m uncomfortable with that notion. We are certainly a flat organization, but really I think servant leadership better describes our model. As COO, I have some leadership responsibility. At Menlo the way you figure out if you are successfully leading is to turn around and see how many people are following.

InfoQ: Well, certainly, from what I’ve seen, lots of people are happily following you here. So something is going right. Can you distill what’s the secret source of Menlo? What makes this work?

James: What I would describe as the most critical part of Menlo is that given all of our tools, our processes, our techniques, none of them are designed to solve problems. They are really designed to highlight problems, make them obvious. At the end of the day, the magic is the humans having the emotional fortitude to roll up their sleeves and have real open and honest discussions about difficult problems and work out what could we possibly do as a solution.

InfoQ: One of the things that’s obvious here, and it surprised me a little bit, is the level of focus that everyone here puts on the rigor and the discipline. Work is work.

James: Work is work. Menlo’s joy is not because we’re having fun instead of work. Joy at Menlo, is defined by doing work that is actually meaningful and accomplishing things that will have impact in the world. So the notion that you should have foosball tables and other fun things at work, doesn’t work for us. Fun is actually accomplishing something of value and getting it out in the world. If we need a mental break, what we do is we go home and do the activities that we love, which are different for each person. So focus on the products and the customers while we’re here and then go home or outside the building and recharge.

InfoQ: You’ve got some things that almost looking from outside would be -- dare I say, it would be seen in other places as micromanagement. People are reporting, tracking their time to 15-minute intervals. Project managers define work for people a week at a time. Tasks are tightly timeboxed. From the outside these look to be pretty arduous rules, but I see the joy. What makes that?

James: There is a lot of rigor. Sometimes visitors see it as simply being very rigid. By rigorously following simple rules, we can each predict how the other participants in our culture will behave, and this makes teamwork far more effective. We don’t have to guess how others are going to behave. We all behave in a way that’s in accordance with these rules. We all work according to the project plan, and if we need to change the project plan, we actually change it. We avoid hallway project management and comments like, “You know, we’ll do that unofficially or when nobody is looking.” Here, if we need to change a plan, we’re going to change the plan and everybody knows it.

InfoQ: Can we explore some of those practices and rules. All work is done in pairs. Haven’t we just doubled the cost to your customers?

James: The vast majority of work is done as pairs. We are still learning how to pair project managers. Everyone else pairs, developers pair, high-tech anthropologists/designers pair, and QA people pair. The obvious assumption that pairing is twice as expensive and twice as much work is logical, but only when compared to some fantasy of how work gets done. If we were really worried about is how fast people could type, then we could hire people who type faster. I argue building software is not a typing sport. A former boss described it as a thinking sport.

Building software was a thinking sport when you could have just one person doing the work, most software development today is a communication sport. How do you get a large number of people to work as an entity trying to get something done? Frequent and effective communications! When you are pairing, you develop far better communication skills and are able to share knowledge across the team rapidly so that team members continuously focus on the bigger picture and can make decisions that add up to a greater whole.

InfoQ: One of the things that I’ve noticed and we did actually talk about at one point through the week was the ability to break some of the productivity rules of our industry: Brooks’ Law about adding people to a late project which makes it go slower, and the overhead cost of switching someone from one task to another. You’re doing both of these things in the teams and not seeing the negative impact that would be expected. How come?

James: I have heard the arguments that keeping the team the same and small is most efficient. I agree with that. I have even made that argument from time to time during my career. The problem that I see, is that being efficient becomes so important to many teams that they stop evaluating if they are being effective. Frequently something outside the project team changes the relative priority of a project. Now the organization would be well served to adapt and reallocate its resources, even if reallocation is inefficient. Being very efficient on low priority projects is not a great strategy for organizational success.

For us, being able to change who’s working on which project in a fluid natural manner that allows us to be productive is a mandate that allows us to achieve our higher order business goals. And that’s a vision that the team members buy into even though an individual may be less efficient for a day. So that becomes a key part of our DNA. Does Brooks’ Law still apply? Yes, but Brooks’ Law assumes that there is a long communication path between two individuals.

So, we optimize our effectiveness within Brooks’ Law by making sure that people don’t have to send emails to each other. They sit next to each other. Everybody who’s working on the same project sits within high-speed voice technology distance of each other. In other words, they’re all at the same table all the time.

InfoQ: All at the same table, I’ve seen one team, 20 people sitting around a single big table, and yet next week, that team might readjust and become six people.

James: Correct. Again, there’s a notion of keeping a team together. And again, I can buy that it’s efficient, certainly, from a team member’s standpoint. But if the business’ priorities changed, and I used to have 24 resources on something, and two weeks from now, the priority changes and I need those people really to work on something else because the business’ priorities have changed; it’s not really efficient to keep those people working on that lower priority task. That’s not an effective way to run an organization.

Now, in order to be able to shift people from one project to the other, we can’t just do it under duress. We have to do it all the time. So we routinely practice moving people from project to project even when we don’t need to.

InfoQ: One of the things we saw was the large number of people who have worked on a wide variety of different projects. That gives you that ability to switch people around relatively easily. One of the things that I have found really interesting in my time here so far is the introduction we’ve had to high-tech anthropology®. What makes it so special?

James: I don’t know of very many projects who don’t have a requirement to make the product easy to use. Some of my colleagues are fond of saying, “Easy to use as easy to say.” There’s a fundamental tenet in how we do our work, “the definition of easy to use is in the mind of the user”, it is not in the technology, it is not in the designer, it is not even in the design itself. So the high-tech anthropology practice assumes if we’re building something for an audience, we need to go understand how that audience works. We need to watch how they behave and act within the context of the product.

So our High-Tech Anthropologists® go study the end user, derive a design hypothesis in the form of multiple potential designs, and then go test those designs in the context in which the user would use them. Evaluating a design by showing it to executives inside of a conference room and the executives say, “Oh, that looks really pretty,” doesn’t mean it will work for the user in the real world. The users might be using the application on a portable device out in the rainstorm and need to be able to see three critical pieces of information clearly.

InfoQ: One of the interesting things about high-tech anthropology is this is actually quite a lot of upfront design. Yet the collective wisdom at the moment seems to be that we want to avoid this big upfront design, or do we?

James: We have projects that try and finish all of the design work first and you can think of that as big upfront design, I suppose. But the question ultimately is how much of the design are we confident in and when should we start building it? So there’s no mandate one way or the other. But the development of the design is also incremental. Let’s work on one part of it. Let’s figure out the key parts of it that are most interesting to the user. Let’s validate those design assumptions.

Then for our customers, there’s a strategic choice. Do you start building the parts that you’re confident in before you finish the design? Or, do you finish the rest of the design before you start building? And that’s simply a set of risk tradeoffs because there’s a risk involved if you wait till you have perfect data, and time passes by, and there’s risk involved if you start building stuff before everything is validated. Which set of risks is best aligned with your strategic objectives?

InfoQ: That’s a simple business risk decision.

James: Simple but not easy.

InfoQ: And I suspect that’s a good way to describe a lot of what I’ve seen here at Menlo. The simple rules you follow, all of the technical practices that come out of eXtreme Programming, such as pair programming test-driven development, continuous integration. Those seem to be just given.

James: Yes. We follow, actually, a lot of rigorous technical practices from many disciplines. We follow many rigorous technical aspects of project management. We build a rigorous set of work packages. We express them as story cards, and we have projects that have over 10,000 story cards.

InfoQ Those are complex projects?

James: Those are large complex multi-year projects with hundreds of thousands of lines of code and teams that have been as small as one pair and as large as 12 to 13 pairs.

InfoQ: And fluctuating over that period.

James: Most complex projects need different amounts of effort at different times during the project. For example, look at the staffing diagrams associated with the Rational Unified Process. These diagrams show team changing size over time. But the practitioners who adapt Rational Unified Process tend to lock resources onto their project because if they rotate off of your project and onto another project, you’re never getting them back. So people tend to assign low priority work to those resources and keep their team size static, even though the methodology suggests you should do otherwise.

InfoQ: Is that an example of what we were talking about earlier on the rules versus the real rules?

James: I would think that’s certainly the case. I also believe that people adapt the process without always fully understanding it or remaining students of it.

InfoQ: Which possibly leads us nicely into a discussion of Agile. It’s crossed the chasm. Every organization out there is doing Agile or sees they want to adapt Agile, is Menlo doing Agile development?

James: Many people who visit us or hear about us come to the conclusion that we are “actually doing it”. My question is, when they talk about Agile, what do they mean? Such that when they look at us, they say, “Menlo is actually doing it.” For example, we pair all the time. Lots of organizations that pair do it whenever they feel it’s necessary. My question is who’s deciding when it’s necessary? So I should probably be using my diet all the time, not just when I think I should. I think that Agile has become an easily adaptive term to which people do not specifically assign an actual set of practices, beliefs, or outcomes.

InfoQ: It has been said which organization would want to admit that they’re not Agile.

James: Well, for us, we’re far more interested. We don’t use the word Agile, but if we’re going to focus on Agile, what we want to see is agility in the business. The business can respond to outside threats and opportunities. That means the business can change its direction. Can the internal technical teams follow the new direction even when it’s inconvenient or inefficient?

InfoQ: Even when it’s inconvenient or inefficient. But we want to maximize the utilization of our resources, don’t we?

James: Being efficient and ineffective is not very compelling.

InfoQ: How would you look at the difference between efficient and effective?

James: In efficiency, we often look at key metrics, and the problem is those key metrics of efficiency change as you go down the way of self-management and deeper and deeper into the organization. So what the highest level executive see as efficient is different than what the mid-level managers see as efficient, which is different than the frontline managers see as efficient, and different still even from the individual practitioners who are building stuff.

So the word efficient to a programmer means “I’m getting a lot of things done.” To the highest level executives, I believe efficient is our resources are getting us closer to our strategic objectives. Those two statements are seldom aligned automatically by using the word efficiency.

InfoQ: How do we make it more effective?

James: I think effective for us is going to be, how do we achieve our primary business objectives? Menlo’s mission is to eliminate human suffering as related to technology in the world. We help our customers build software solutions that end users love and can help the business achieve its business goal. We have to weave that all the way through our process and that have to be part of the conversation all the way down to two developers sitting down making a business decision when they’re making a small choice inside of the code. In order for that to be the case, we can’t use it through trite sayings. It means there has to be an ongoing discussion between the business and the technical team throughout every project.

InfoQ: How do you bring that in?

James: Every week at minimum, there is what we call show and tell. Our partners in business would come in and test whatever we’re building to see how it’s working. They will then review the project plan which is very similar to what’s described as the planning game in eXtreme Programming. And update the project plan in accordance with what they’ve seen we’ve accomplished, in accordance with whatever data we’ve produced about our current estimates or options, and what they are hearing is changing inside of a business context.

Layer this on top of the High-Tech Anthropology® where we’re actually paying attention to what the end users do with the software or our prototypes of the software or our paper mockups of the software. Then we are driving towards how do we get the behaviors we need from the end users that produce business outcomes.

InfoQ: What about the common challenge we hear from IT groups - but our business hasn’t got the time to come and talk to us once a week, they’re too busy.

James: We see lots of examples when we get to meet with other teams where the business side is too busy or doesn’t have time. What we often see in this context is that the IT team is expecting the business to learn IT and to learn Agile, instead of seeing their responsibility of meeting the business side on their terms. So, all of our story cards that we write are what package definitions are written to be understood by the business side. If they’re not understood by the business side where we build them and redesign them so that they do fit what the business understands, rather than try and teach the business about how the database works or what infrastructure is like.

So the whole need of connecting with the business for us is we go reach out to the business and find a way to communicate with them on their terms. I think a lot of teams struggle because they expect the business to come talk to them because they’ve declared we’re now Agile.

InfoQ: One of the things I have heard you say this week is that you’ve actually walked away from work where the customer is not prepared to align with this approach. How so?

James: Well, I think it’s ultimately pragmatic. If we have a customer who’s really excited to use Menlo because we’re Agile but they don’t really buy into the collaboration and the difficult decision making that is truly involved, then we’re going to end up with an unhappy customer. And in the course of my career historically, I’ve been in places where we had an unhappy customer who didn’t pay their invoices, the company didn’t get paid, but because we successfully completed the project, I got bonuses, which is really a false economy. So the goal of accepting a project for which we don’t believe we can get to a successful conclusion is not very compelling.

InfoQ: What is The Business Value of Joy?

James: A team that sees value in what they’re doing. Often the tasks that we have to do in IT are hard, arduous, sometimes boring. Sometimes, one has to fill out paperwork, which we’ll still have in our environment for certain contexts when we work inside of regulatory industries. But when the work has a higher purpose and you can see how it will have impact in the world and you can accomplish something bigger than yourself, most individuals are willing to work very hard in order to achieve that because when they achieve it, they feel joy.

This is the same joy that we argue people will feel when they run the marathon. Running a marathon is hard. It’s painful. You see people cry at the end. They’re not crying because they’re happy. They’re crying because it’s joyful. The arduous process of building software isn’t always happy. But if we achieve our bigger goal, then it could be done by ourselves sitting in a room. That can be incredibly powerful. So that joy creates energy that allows the team to have power through difficult times in order to accomplish big things.

InfoQ: Well, certainly from what I see, Menlo is accomplishing big things. James, thanks very much for taking the time to talk to us. It’s been, for me, an inspirational week.

James: Well, thank you for joining us for a week. It’s always a pleasure to share what we do and why we do it with others.

About the Interviewee

James Goebel is a founding partner of Menlo Innovations. Menlo uses highly collaborative project teams to design and implement innovative products for clients that place high value on user adoption. James has worked in a variety of environments, from 2 employee startups up to billion dollar organizations. As a coach and change agent, James has helped organizations achieve dramatic transformations in both process and culture. He enjoys speaking at conferences, teaching classes, and speaking to small local groups in order to share the lessons he has learned. James is a certified Project Management Professional (PMP), a certified Scrum Master, and has an MBA from Eastern Michigan University. He has practiced software product development for more than twenty years as a developer, team lead, system architect, project manager, practice director, and executive coach. For the past fifteen years he has been building and managing Agile software teams.