# data[].attributes.body
Create central intake that all on Tech Advisory can see and comment on how their tool can solve the problem.

# data[].attributes.body
The silo is created by my knowledge of a particular skill set. When I am in a silo, others cannot learn what I know. Those in the silo do not have people to bounce ideas around with

# data[].attributes.body
Create opportunities to actively share my SF knowledge. Share what SF can do.

# data[].attributes.body
Project Managment: https://basecamp.com/

# data[].attributes.body
Collaboration: https://trello.com/

# data[].attributes.body
We have time on the team calls for updates, but we don't have regular time to connect on specific projects that we aren't assigned to.

# data[].attributes.body
Establish norm of working through "intake process" or the "solution building process" as an open setting where advisory team members outside of the project can dig in. Maybe set it up as "opt out" instead of "opt in".

# data[].attributes.body
We could make a step in each project plan to have collaboration at the beginning, and the whole team has visibility into it.

# data[].attributes.body
This isn't new, but we could commit to more transparency of our projects by keeping intake notes in a shared space in a standard format.

# data[].attributes.body
Adding this as an example where we might want to keep a silo to reserve more capacity to support a broader range of contracts.

# data[].attributes.body
I think we intentionally encourage specialization based on level, skills, and interest.  That has allowed us to support a broader range of contracts then we used to.

# data[].attributes.body
PST and Cross Site Data are some recent examples of us working in silos. We were able to respond and adjust quickly because we didn't stop for an internal design discussion, but we did run into problems with the implementation. Maybe we would have landed on a better solution quicker if we had a broader range of design ideas.

# data[].attributes.body
Recent email response to a request from Emily Appel:  Hey Emily!  Adding Adele so she can connect you with the best person on our team to talk next steps.  We’ve done something really similar to this in Duval, and since then we’ve developed a template for Academic Diagnostic walkthroughs that we might be able to repurpose for this.  We’ve also been using a data collection platform for SEED that’s low cost which might be a good fit here.  Can you please let us know what your timeline is for the proposal, when you’d like to start collecting data, and when the area superintendents need to see the first report of results?

-Ranjeet

# data[].attributes.body
We could standardize on a few platforms/solutions. I think it would limit the breadth of contracts we could support, but it would allow to be more cross functional.

# data[].attributes.body
from Ranjeet

# data[].attributes.body
Not a tech fix and it's super annoying, but it is effective. At Motorola we had a rigidly defined process for each stage of a project (proposal, requirements, design, build, test, and deployment). We also had weekly reviews where everyone shared status using the same project template. Very bureaucratic, but anyone on the team could drop into any project at any point and pick it up quickly.

# data[].attributes.body
thoughts about running this using Jira?

# data[].attributes.body
Maybe we talk about so much we are less likely to get specific feedback on parts of projects. maybe if we have a standard process, something that signals the convo as less of an update and more of a discussion, that would help. Interesting to see cross-site as an example of silos bc we had several discussion about the approach on team calls in the fall , but again, maybe that's because it sounded more like updates than feedback?

# data[].attributes.body
I wonder if having too many solutions unintentionally creates silos because there's not enough time to get up to speed on various projects and options. maybe fewer solutions would create more collaboration

# data[].attributes.headline
Time reserved specifically for feedback/part of our weekly work flow

# data[].attributes.subject
Time reserved specifically for feedback/part of our weekly work flow

# data[].attributes.body
maybe if we said everyone should expect to spend xhrs a week on collaborations/feedback that gives us a sense of timing. we could add the code to replicon or just add to central time

# data[].attributes.body
for intake form process + high level project streams + reference / update for our team advisory meetings?

# data[].attributes.body
Not that anyone is intentionally doing this but...We segment our work into ‘projects’ which historically have been led by project directors, all of which might have their own vision, strategy, and experience sets that yield ‘solutions’ which ultimately creates less synergy, forward momentum, and alignment

# data[].attributes.headline
Rigorous debate = sign of digging deep into the 'right' solution

# data[].attributes.subject
Rigorous debate = sign of digging deep into the 'right' solution

# data[].attributes.body
I think we lack this in our small group

# data[].attributes.body
When year 1 solutions start feeling like year 4 solutions ... maybe we aren't making progress?

# data[].attributes.headline
Common use case scenarios = playbook opportunities

# data[].attributes.subject
Common use case scenarios = playbook opportunities

# data[].attributes.body
Sample scenarios:

School network X wants to collect grant or business metric data and report out on it

School network Y wants to implement interim system Y for 1-2 years while they conduct deeper dive into long-term solution

School network Z wants to conduct a gap analysis and recommendation set related to current data / system landscape vs. future (best practices)

School network X wants to conduct a vendor analysis related to system type X

# data[].attributes.body
Sustainable, transferable, effective, integrated, manageable, adaptive, scalable, market relevant — all important words that I think we should balance to find the best solutions

# data[].attributes.headline
Tech advisory team meetings = hub of thought, preview, and next step connections

# data[].attributes.subject
Tech advisory team meetings = hub of thought, preview, and next step connections

# data[].attributes.body
Team meetings leveraged primarily for discussion around solutions and strategies, preview new projects, quick updates, and further coordination to ensure project success

# data[].attributes.headline
High level project monitor that includes...

# data[].attributes.subject
High level project monitor that includes...

# data[].attributes.body
(Visual) Norm around high level but *formal* project documentation that includes:

Start / end dates

Context

Category or use case: data, new systems, etc.

Solutions

Owners

Other??

# data[].attributes.body
I think we all are doing this organically to solve problems and build appropriate tech options for use cases but how do we align, document, and norm this the process?

# data[].attributes.body
Making more connections on related workstreams and cross team planning

# data[].attributes.body
When working on projects, working from a set list of systems and processes