As a test, I recently requested that Grokipedia update its page on OpenSolaris to include the source code release history I kept while I was the community manager. There were over 80 releases of source code, entire projects, and technical documentation during the five years of the project. I kept the history here. Anyway, I submitted the request to Grokipedia, and a few hours later the page was updated. Just like magic! That’s pretty much impossible with Wikipedia since I’m not one of their chosen editors. In fact, many years ago I tried to make changes to pages on Wikipedia and they were reversed seconds later. So, good on Grokipedia. I’ve long since given up on Wikipedia so it’s great that Grok is moving forward with a new community-driven encyclopedia.

Still the best quote I have about how to move an idea forward among a group of Open Source kernel developers. Pure gold.

Back on OpenSolaris years ago we had a lot of community conversations and flame wars that started out with the “Why don’t you just …” construction and then things spun around from there. At various points (usually after hundreds of such mails) the kernel engineers would occasionally chime in with a precise gem like this one below. Get to work. Write something.

[ogb-discuss] Re: [osol-discuss] Re: Project Proposal - (what is/was Indiana)

Bryan Cantrill bmc at eng.sun.com
Thu May 31 15:41:47 PDT 2007
Previous message: [ogb-discuss] obtaining a contributor grant

> More source code and less comments/opinions!

Yes, please. I don't think one can necessarily fault the OpenSolaris community for being bureaucratic; if a project wishes to lead with the process and follow with the prototype, life will naturally feel very bureaucratic. I (rather strongly) believe that this is _not_ the way that software should be developed; in software, ideas are expressed in _code_ -- the implementation _is_ the idea. If an idea has not been implemented, it is (in my opinion) premature to call it an "idea" -- it is rather a notion, a daydream or perhaps a fancy. If one has such a thought, the first order of business is not to send out proposals or give speeches or navigate through process but rather to sit down and write some code: build a prototype, share it with some like-minded people, incorporate their feedback, expand the community (note, lowercase "c") and iterate. If one does this and one's ideas are sound, the process (in my experience) naturally follows; people naturally gravitate to good ideas.

This is not to say that the OpenSolaris processes can't be used to help this process of iteration -- just that they should be used to help the process, not initiate it.

	- Bryan

Over the years I’ve worked on teams in construction, marketing, publishing, and software. I ran my own excavating business, built and sold homes and raw land, drove multiple big-rig trucks, and fixed heavy equipment as a mechanic. I also wrote magazine articles and managed publicity campaigns for companies and universities and worked with governments and media outlets around the world. Later I joined Sun Microsystems and Oracle, where I helped build Free & Open Source Software (FOSS) communities, ran global developer conferences, hosted multiple podcasts and video channels, and interviewed hundreds of engineers, scientists, physicians, and other technical professionals.

This disparate mix of experiences has shown me what separates strong teams from weak ones. Strong teams produce excellent work when they have clear roles, open communication, and a genuine focus on merit, quality, and service. But weak teams fall apart under poor leadership, bad planning, or cultures that punish people for speaking up. The best teams make life easier for everyone. People grow, the work gets better, and the whole group thrives. When I join a team, I look for these qualities. If they are missing, I move on if possible. I don’t stick around in places that waste my time.

Building a Strong Team Culture

The strongest teams come from managers who build their teams with purpose and maintain them with steady effort and improvement. These managers create a culture centered on merit, collaboration, and real chances for individuals to grow. They make sure everyone can share ideas and skills, regardless of position or experience. Effective managers also judge work by its quality, not by politics or personality. That builds trust and draws out the best from the team. It also sends a message that merit is the standard, not favoritism.

It starts with hiring. This lays the groundwork for everything that follows. Innovative managers tap current team members early in the hiring process. They collect input from everyone before interviews, include several people directly in discussions with candidates, and review feedback as a group afterward. This gives the entire team ownership and helps find people who fit the culture. Unfortunately, many managers skip this step entirely, which can weaken the team and reduce retention of people who have been producing great work all along. Nothing is more frustrating to the team than having to welcome a new team member you know nothing about and who may not fit.

When a new person starts, effective managers provide solid support right away. They pair the newcomer with an experienced teammate to speed up learning and answer questions as they arise. They share the team’s history, past projects, and major wins so the new member gets the context fast and begins contributing soon. This early investment in onboarding shapes how people view the team and their role in it for years to come.

Overall, the team’s structure, projects, and tasks should be well documented by the manager on an internal wiki that everyone can contribute to. Everyone should know what everyone else is doing. Clear roles are important. They cut down on confusion and lost time. Strong managers define and document these responsibilities, and then let people learn through actual work rather than just instructions. It’s natural for teams to evolve, so these managers watch the dynamics and adjust as needed. They shift workloads when necessary, invest in skills that matter, and improve processes continuously. They create safety so people can admit mistakes or question assumptions without fear. Most of all, managers like this foster pride in high-quality work. They value excellence in every detail, from code to documents to any other output team members produce. They also run blameless reviews to learn from issues without blaming individuals, which encourages honesty and speeds improvement.

What Effective Managers Do

Managing people takes real skill, study, and practice. The best managers balance care for the team with care for the work. They track short-term needs and long-term goals and opportunities at the same time. They stay reliable and visible and avoid jumping between tasks in ways that kill momentum. They protect focused time for the whole team, including themselves, because deep work that generates the most value requires sustained attention that constant interruptions destroy.

These managers look at data to make decisions, but they also know that numbers miss the full picture. People and projects have hidden layers that do not show up in reports. Effective managers welcome needed change but offer stability when things feel shaky. They plan for surprises and guide the team through tough shifts while keeping core goals clear. This balance between flexibility and steadiness marks the difference between managers who keep teams grounded and those who let chaos run wild. They shield the team from distractions and politics that drain energy without adding value. They advocate for people, block unnecessary pressure and distractions, and they keep communication solid especially in rough times. They reply to messages quickly and completely, share clear updates, and use shared channels so no one gets left out. They know instinctively that weak communication breaks trust fast, and once that erodes, it takes months or years to rebuild — if it can be at all.

Conflicts happen in any group, but capable managers handle them directly and calmly. Dodging problems makes everything worse because unresolved tension spreads through the team like a slow poison and can kill a team over time. Performance reviews receive serious attention from these managers. They give honest feedback tied to observable work and real impact. Nothing surprises anyone in a formal review because the conversation has been ongoing throughout the year. They deliver hard feedback privately and early when course corrections still feel manageable rather than catastrophic.

What Team Members Contribute

Everyone helps the team succeed. Strong managers set the tone, but capable contributors are encouraged to take initiative, own their tasks, and support colleagues in ways that multiply the team’s effectiveness. Everyone arrives prepared, on time, and engaged in meetings. They follow simple etiquette, mute when not speaking, and give full attention to the discussion at hand. They join team events to strengthen relationships and step up for tasks that build skills or help others, even when those tasks fall outside their formal job description.

They avoid multitasking because it harms productivity and leads to shallow work that satisfies no one. Instead, great performers handle several commitments by completing them one after another and meeting deadlines through focus rather than frantic juggling. They stay flexible when priorities change, which happens more often than anyone likes. They seek feedback on their work and offer constructive input to others, creating a culture where improvement becomes normal rather than threatening.

Team members make their schedules known, set regular hours, and stay reachable during work time so colleagues can count on them. In distributed setups, everyone posts updates and respond promptly because remote work depends on trust that people will follow through without constant supervision. Communication drives progress in ways that matter more than individual brilliance. Contributors share their current work, ask for help when needed, and clarify expectations before diving in. When they discover a problem, they articulate the issue and show up with a fix. They use team channels for group topics so everyone benefits from the discussion so issues are resolved fast. They send short status updates that keep people informed without overwhelming them. They praise in public and give critical notes privately, which builds morale while still addressing problems. They follow processes, document work well, and connect with outside communities when projects require it, which helps to bring fresh perspectives back to the team.

What First-Line Managers Handle

First-line managers set the culture and deliver results in ways that shape daily experience more than any executive mandate. They balance growing people with shipping projects, and they know that neglecting either one undermines the other. They run regular one-on-ones that go beyond surface chatter to address real concerns. They provide steady feedback throughout the year and ensure annual reviews hold no surprises because the conversation has been open and continuous. They mentor directly or link people to solid mentors who can offer the guidance they themselves cannot provide.

They open space for real talks about work struggles or personal matters that affect performance, recognizing that people bring whole lives to their jobs even if private issues go unstated. They back career moves, even to other teams, because keeping someone in a role they have outgrown helps no one. They keep roles defined and show how work ties to bigger goals so people understand why their efforts matter. They build unity through shared experiences that create bonds beyond the purely transactional. They resolve conflicts fairly, involving HR only when required by handling most issues themselves before they escalate.

First line managers are active and observant. They plan for turnover because people leave, and pretending otherwise leads to knowledge loss that can cripple the team for a time. They cross-train to share knowledge across team members so no single person becomes a bottleneck. They track time off to prevent gaps that leave the team understaffed during critical periods. For projects, they craft a clear vision with team input rather than dictating from above or focusing on their favorite employee. They assign tasks wisely based on skills and growth opportunities. They track progress without hovering, trusting people to deliver while staying alert for problems. They use practical metrics that reveal actual progress rather than vanity numbers that look good in reports but mean nothing. Unlike executives or second line managers, these first line guys are much more involved in the day to day operations, and so they must be sensitive to changes taking place under the surface of all the activity.

They push for needed resources and represent the team upward, making sure leadership understands what every member of the team needs to succeed. It’s obvious to individual contributors when they are left out of upline reporting, and these managers know that and never make this mistake. They communicate consistently with the team, their bosses, and peers across the organization. They raise problems early when solutions still come cheap rather than waiting until a crisis forces expensive fixes. They foster trust across groups because most work now requires collaboration that crosses team boundaries. In distributed teams especially, they ensure meetings feel fair by rotating times and giving remote voices equal weight considering their time zones. They spell out confidentiality clearly so people know what they can share and what must stay private.

Running Effective Meetings

Meetings move communication forward when done well, but poor ones drain time and energy without advancing any real purpose. Capable managers send agendas in advance so people can properly prepare and contribute meaningfully. They share notes after the meeting and archive them for reference, which focuses the conversation and lets absentees catch up on what they missed. This simple discipline prevents the endless rehashing that wastes time in teams with poor documentation.

They start and end meetings on time to honor schedules and prove that focused work matters more than performative presence. They hold one-on-ones to strengthen relationships and spot issues early before they grow into problems that require formal intervention. They limit surprise meetings to true emergencies to protect deep work time periods because every unplanned meeting interrupts focus that takes time to rebuild. They encourage all voices in the room. If someone stays quiet often, they check in privately to understand whether the person has nothing to say or feels unable to say it. Most people who stay quiet in meetings are hiding something and that’s a management problem. Standups remain brief, centered on blockers and decisions rather than detailed status reports that belong in written updates or team discussions.

They hold retrospective meetings when needed and turn findings into real changes rather than treating them as box-checking exercises that produce nothing. The best retrospectives create concrete action items with owners and deadlines. Without that follow-through, the retrospective meetings become cynical rituals where people stop contributing honest feedback because they know nothing will change.

Handling Distributed Teams

Distributed teams face extra challenges from time zones, languages, cultures, and economics that managers cannot wish away with talk about “global collaboration.” Strong managers tackle these directly rather than pretending geography does not matter. They push asynchronous work with good documentation, clear status reports, and written decisions that people can reference across time zones. They rotate meeting times occasionally so the burden spreads fairly instead of forcing the same people to join calls at 2:00 in the morning every week. It’s always nice to give everyone on the team a sense of what everyone else has to deal in remote geographies. The vast majority of managers ignore this issue entirely.

Remote members can lose out on influence when managers favor people they see in person, so effective managers counter that tendency deliberately. They may give remote voices priority at times to compensate for the natural advantage of those who are meeting in person. They move key discussions to text in a shared mailing list where everyone can participate equally. They monitor promotions by location to fix unfair patterns before they calcify into structural inequality. Non-native speakers may get extra time to formulate thoughts in a language that does not come naturally. Managers avoid jokes or phrases that exclude people unfamiliar with local references, and they judge on work quality rather than polish in communication.

Managers who understand international work actually study cultural communication styles because directness that works in one culture can seem rude in another, and consensus-building that one culture values can look like indecision somewhere else. They focus on results rather than matching a certain way of speaking, which often masks cultural bias as professional standards. They design budgets fairly so development chances feel equal regardless of where someone lives. When conference travel or training opportunities consistently favor certain locations, resentment builds and talent drains away from the teams that need it most. Remote team members feel these things immediately, but only a few consciousness manages are aware of this.

Representing the Team

Good internal management needs strong external advocacy because teams do not exist in isolation. Capable managers keep leadership updated on progress, risks, and issues early when interventions still work. Surprises hurt trust because executive leadership needs time to process information and adjust plans and budgets. So, managers need to highlight achievements, particularly for remote people whose work can stay hidden from executives who notice whoever sits near them or who has access to them. In large organizations, good work needs promotion because it will not speak for itself, so great managers share everyone’s work deliberately through newsletters, emails, demos, and presentations that get the team’s name in front of decision makers.

These managers align team efforts with company priorities and shift direction fast if something no longer matters to the business. Holding on to pet projects that leadership has deprioritized wastes time and marks managers as unable to adapt. They nurture relationships with peer teams ahead of time so they have goodwill to draw on when collaboration becomes necessary or when problems need resolution. Solid links ease joint work because people already know each other and trust that requests will get handled fairly. Without those relationships, every interaction starts from scratch and burns energy on establishing credibility that could go toward solving problems.

Delivering Results

The best teams ship quality work on schedule because reliability earns trust that opens doors for future projects. Effective managers set realistic timelines and meet them rather than promising the impossible and disappointing everyone. They favor consistent delivery over rushing to meet arbitrary deadlines that produce crappy work requiring expensive fixes later. When changes come, and they always do, these managers communicate them clearly, reset expectations with stakeholders, and explain the reasons so people understand the decision rather than resenting the disruption.

Well run team build quality products from the beginning with testing, reviews, and rapid feedback loops that catch issues early. Problems that are found in development cost far less than problems found in production, so investing in quality up front saves time and money. Managers running these teams identify problems quickly through monitoring, user reports, and team observation. They resolve them before they escalate into crises that pull everyone into emergency mode and destroy planned work for weeks.

Learning and Growing

Teams stay sharp through continuous improvement that treats learning as essential rather than optional. Strong managers fund conferences, courses, and certifications because everyone knows that skills atrophy without ongoing investment. Learning should be a priority that gets time and budget rather than something people squeeze in around real work. Team members should be encouraged to carve out work time for experiments and side projects because fresh ideas often emerge from open exploration that has no immediate business justification. Markets change rapidly. Preparing for the future needs to occur in the present.

Teams can easily grind themselves down from over working or working on low value or meaningless projects. So, observant managers watch closely for this. They look for burnout through signs like stress, short tempers, or people who quietly pull away from colleagues and activities. They adjust loads early to keep a steady, sustainable pace because burned-out teams produce poor work and lose people to competitors who offer saner conditions or more interesting projects. These managers run retrospective meetings after projects to pull lessons and break bad patterns before they become embedded habits that shape everything the team does.

Connecting Work to Real Impact

People perform best when they see the value in their efforts and understand how their work affects real users or business outcomes. Capable managers continually explain how the team’s tasks link to business goals, customers, partners, or the greater community in concrete terms rather than vague platitudes about innovation and excellence that are backed up by nothing. These childish statement are obvious, aren’t they? Instead, great managers make the connection obvious and reinforce it with data often because the link between daily work and the larger purpose gets lost in the grind of tickets and deadlines. It’s the responsibility of the manger to make these things clear.

Great managers also keep end users front and center so the team solves actual problems rather than building features that seem clever but serve no real need. They pass user feedback directly to the group in detail complete with quotes and context that make the people behind the data real. They recognize wins publicly with information that shows what the team accomplished and why it mattered. This lifts everyone’s spirits and shows what the organization values, which shapes future work more than any strategy document.

Giving Autonomy and Ownership

Strong teams empower people with ownership that makes work meaningful rather than treating them as interchangeable resources executing orders from above. Effective managers define clear goals and limits, and then they trust people to decide inside those bounds how to reach the objectives. This is critical for establishing trust, which accelerates work and sharpens judgment because people learn from their own choices. Micromanagement, on the other hand, stifles drive by signaling that managers expect failure and must control every detail to prevent disaster. It also reveals a weak manager who lacks confidence.

Autonomy is critical. It promotes accountability because people are encouraged to own both their successes and setbacks in a blame-free space that encourages honest assessment. Managers who promote autonomy encourage their people to openly talk about errors because learning speeds up when people can admit mistakes without fear of punishment. These managers assign stretch projects with support to build skills that formal training can’t provide. As a result, growth occurs when people are encouraged to tackle hard challenges safely but with backup available if things go wrong. And they sometimes do. But this freedom is important so people try approaches that might fail. That’s what generates new opportunities.

Great managers also spotlight top work openly to prove that merit counts for everyone, not just the favored insiders that many times emerge when groups form over time. When promotion and recognition follow visible achievement, people believe the system works fairly and they invest their best efforts. But when politics and favoritism determine who advances, talented people disengage or leave for places that reward their contributions. How many people on your team have long ago quietly quit with a smile on their face?

Final Thoughts

These observations come from working on teams across multiple industries and also from conversations with hundreds of professionals who built, led, and contributed to successful groups. Teams change, challenges shift, but clear communication, mutual respect, and commitment to merit and excellence endure across contexts. Take these ideas as a foundation. Adapt them to your situation. Refine them as you learn what works in your own environment. And good luck creating great teams.

I’m always looking for opportunities. I learned that from my father, who never let an opportunity go unnoticed. Opportunities may seem rare but that’s not true. They’re common. They’re flying all over the place. The issue is that we miss them because we’re too distracted, or when we spot them we’re too afraid to grab them. The only way around this problem is to practice. Try one. Fail. Learn. Try again. Get it! Start small so you don’t risk too much. Scale that process over time. Simple.

This opportunity bit is critical because life is brutal in that it can wreck anything it sees at any given moment. We need to implement as many opportunities as we can just to break even! Remember, it can take decades to recover from some crash life delivers. Or sometimes there is no recovery at all. I know this to be true. Painfully.

I think about this all the time because I’ve missed so many opportunities over the years — but I’ve captured a few along the way as well. A big one I leveraged a while back is represented by the image below. That’s Atul Chitnis. He used to run a software conference in Bangalore called FOSS.IN. I met him via my friend Danese Cooper. Back then I was on the OpenSolaris project at Sun, and I had a community development presentation I was working on. I didn’t really have much experience delivering sessions to large audiences, but Danese thought I’d be good and she said I should submit my presentation to the conference. She also contacted Atul and recommended me. I then spoke to Atul myself and pitched my story. He bought it! I got a session on the main stage! That was my first OpenSolaris session at a real FOSS conference. This wasn’t a vendor sponsored thing. It was real.

My point is that we all need help. We can’t do anything alone around here. That’s why our network is critical. Look for people who will give you a shot. It’s possible your network contains connections you can’t easily see. Keep looking. Keep practicing. Keep pithing.

Atul is no longer with us. He passed in 2013 but I think of him and appreciate that he gave me an opportunity.

I remember a discussion on one of the OpenSolaris mailing lists long ago when kernel developer Bryan Cantrill said that ideas are expressed in code and that the implementation itself was the idea. I love that!

His statement was probably in response to some meandering thread where people were just talking in circles and not doing anything. I remember at the time many engineers feeling the same way about such conversations. And I know from my construction days that most contractors and craftsmen got that concept as well. So, don’t just talk. Write something. Build something. Do something. That’s what gets attention. That’s when the conversation begins.

Image: Adam Leventhal, Bryan Cantrill, and John Gage at SunNetwork China in Beijing in 2004.

Meeting Linus Torvalds at the Open Source Summit in Tokyo in June 2018.

I’ve crossed paths with Linus Torvalds at many events throughout the years, but this was the first time I actually met him and spoke with him. I waited until after his keynote and walked up to the stage, along with dozens of Japanese developers. He stayed afterwards and spoke to everyone and signed shirts and books for about a half hour. I stood off the side of the line and just took photos and listened in on the conversations. When he was finished chatting with everyone I introduced myself and we walked out into the hallway. I mentioned that I was the OpenSolaris Community Manager at Sun. He stopped, looked up, smiled, and said, “Oh, I’m sorry!” And we both laughed. I still have bittersweet feelings about Sun and OpenSolaris. It’s a shame how it all ended. I went from working on the hottest project at Sun at the time and being Sun’s #1 blogger (see: BSC front page (hits refreshed daily) to losing those platforms virtually overnight. That wrecked my career and forced me to reset yet again.

Then I told him about the time I spammed the Linux kernel mailing list with my OpenSolaris announcement back in 2005! It was an accident, of course. You see, we had been collecting emails on our website from people who wanted to be notified about the upcoming OpenSolaris announcement. We had already released the DTrace code in January 2005 but hadn’t yet opened the entire kernel. That bit was set for June and then there would be many releases after that. So, for six months about 10K people entered their email address into our web form, and obviously some special friend keyed in the Linux kernel list for kicks. Sure, we didn’t look at or clean the list for spam, but hey, we were all very busy. That OpenSolaris launch was quite a challenge.

Here is my announcement.
Here’s my apology.
Threads from the day (search for OpenSolaris)

Embarrassing. But a lesson well learned. And a good laugh years later with Linus himself. He did ask if I was treated ok by the community after the gaffe, and I said I was. All good. Anyway, we had a good conversation about Sun, Oracle, Linux, and the FOSS community. I’ll take it.

Message to the OpenSolaris Pilot Program

And finally, here’s the private email I sent to the OpenSolaris Pilot Program the day before I spammed the Linux community on OpenSolaris launch day. We ran a private pilot program for a year before we opened the project and those few hundred developers became the seeds of the new OpenSolaris community.

[osol-discuss] Good Luck and Thank You

Jim Grisanzio Jim.Grisanzio at Sun.COM
Mon Jun 13 17:27:01 PDT 2005

---

Hello, OpenSource Pilot Community.

I just wanted to chime in before the fur really flies around here:
Good Luck, and Thank You!

You all deserve Sun's thanks for your efforts and your patience this year. It should be wild day tomorrow, for sure, so light up those blogs and start talking, guys. The engineers are leading this launch tomorrow, make no mistake about it.

Oh, and if you want to bring someone into the program, you *don't* have to call me and sign another f****** NDA. Just do it. I can't tell you how happy I am to not have to dig out another NDA. Not that I could read the damn thing but whatever. It's such a cold way to start a friendly little conversation, don't you think? Also, I've tried to honor as many of your requests (and those from internal people) as possible to get people into the program. We ended up with 145, but quite frankly, dozens and dozens of developers never made it in due to lack of time or resources. We even had a dozen Chinese engineers all briefed, translated, and NDA-signed but couldn't get export control approval in time. It drove me nuts for three months. I'm more than a bit pissed about that one.

Anyway, I hope you are happy with the results of what we are all releasing. The core team here has worked almost non-stop for weeks on this to get ready for the final push. We wanted to do more, you know that, but hey, look at where we were last year and look at the potential tomorrow brings. Also, the OpenSolaris team internally really has been genuine in their intentions, I can assure you. At times we've not been as open as we could have been -- we get that -- but I hope you believe me when I say that many people on the team fought hard on your behalf all year long. Every time you told us we were full of shit on something we took it to heart and it went up line. There were a few, ah, heated,
conversations regarding some of the issues that were discussed in the pilot. We won some and we lost some, but every time we moved a little closer to our goal of openness. As you've seen, this stuff takes time. I wish we could have exposed more of that process to you. Next time it will probably be easier to do that.

As this program has grown it's garnered attention from all across Sun and from Sun's competitors and supporters. Just recently, I've heard from executives and engineers traveling to South America and to Asia, and they report that there *absolutely* is massive community interest out there. Even Wall Street has noticed. Some people are probably a bit confused since the Solaris community was supposed to be dead by now. Well, too bad. It's too late. They lost their window of opportunity to crush us. Our next step is to stay positive and to engage the interest we know is there, make it tangible, and grow this OpenSolaris community. In a very real way, you've all been part of something special here. You've helped change this company and potentially an entire market along the way. Some people may not know this quite yet, but they'll surely find out tomorrow. You are some of the most knowledgeable people in the world about Solaris, and you've help make OpenSolaris a possibility. 

Congratulations and we'll see you on the other side.

Jim